On May 7, 12:50 am, Martin Trautmann <t-...@[EMAIL PROTECTED]
> wrote:
> Correction: I may have found the bottleneck: Each line contains a
> calculated field which is composed from related data within the other
> file. Thus it is an unstored calculation, while the FMP6 solution takes
> a calculated text field instead.
Yes, that could make a difference.
> One of my major wishes for FMP would be multi-cell copy/paste, as I can
> do within spreadsheets. Currently I have to go via ex****t/edit
> externally/im****t (replacing field contents), which is always more
> dangerous. Oh, BTW: multilevel undo for this edit operation would be
> usefull, too :-)
A multiuser database isn't a spreadsheet. How does a multilevel undo
work in a system where multiple users may have updated the record
prior to your request to undo? What if you've done a relookup on 4
billion records? Where is it going to store the gigabytes of undo
data? I'm not saying I disagree -- but the semantics of what these
features would be is quite a bit more complicated. And an undo that
only works some of the time is possibly more dangerous than not having
one at all. At least by not having one at all, you'll hopefully take
the time to make backups. :)
> Yes, this is
> an edit operation that might slow down things - point taken, I might
> ensure to leave fields.
FYI 'Leaving fields' does not commit the record in FM7+
> I do the "print" operation, as indicated within the subject.
The word 'print' becomes sort of indeterminate when one is referring
to pdf file generation.
> > You should try "Save Records as PDF" if you haven't.
>
> Here's a first sample, a bigger part with 6210 found records.
> 9:09:29 begin
> 9:09:29 find finished
> 9:10:31 sort finished
> 9:10:34 window changed to layout, preview
> 9:13:32 print finished
> 9:13:32 file rename by AppleScript finished
>
> Thus sorting took 62 seconds, printing took 178 seconds, other jobs
> required time slots of minimum length.
>
> Same run with "save as pdf" instead of print to pdf:
> 9:27:42 begin
> 9:27:44 find finished
> 9:28:29 sort finished
> 9:28:33 window changed to layout, preview
> 9:31:22 save finished
> 9:31:23 file rename by AppleScript finished
>
> Sort was faster this time - probably some cached effect, 45 seconds
> only. The window switch is something I want since most of the times I do
> print just a few files, instead of several hundreds. Thus I do accept
> these few seconds each time.
> Save took 169 seconds - that's a certain speed improvement.
> But the printed PDF takes 416 KB for 57 pages as PDF 1.3,
> while the saved PDF takes 1.2 MB for 57 pages as PDF 1.4
>
> Did I miss the point how to use a "save file as"?
Different PDF engines and versions will all result in different file
sizes. 1.2MB certainly isn't as good as 416KB but I've seen bigger
differences before. Under specify options try to change the Adobe pdf
version it outputs, that will probably make a difference... I can't
say whether it will make it bigger or smaller though. You can set it
to Acrobat 5+ or Acrobat 6+ on the windows version, not sure what
options you'll have on the mac.
Also check the OSX save-as-pdf options -- there may be differences in
artwork resolutions, page scaling, and so on that might be going on.
(If for some reason its scaling the page even 1% to "fit", for
example, that could be a HUGE performance hit)
Not that you want to run a separate batch process after the fact, but
there is software that can strip out all the needless meta-data crud
in pdf files that isn't required to view them and generally reduce
them by 50-90%. Probably can shrink the OSX pdfs down too.
Might be worth doing in any case, even it takes hours, just to save
space, and speed them up if you serve them over the internet.
----
Given that you've established that of the ~300 seconds re****t takes to
generate, ~180 seconds are spent in the printing step, I'm now
convinced that at least a significant part of the bottleneck is the
printing step itself.
So lets look at that -- start playing around with your re****t layout
itself. Eliminate borders and any overlapping objects for example. It
may be the the new filemaker is passing more complex do***ents to be
rendered into pdf. Sure they might -look- the same, but perhaps inside
they are very different... and the differences may make them much more
time consuming to render.
I'd work up from *completely* blank white pages (set up the 'parts'
but leave them blank) to the full re****t, trying both the save-records-
as-pdf script steps in all formats as well as the OSX save-as-pdf. So
that we can see what each engine does, and how its affected at each
step.
Then add one piece at a time, and time it in all engines / pdf
versions. I expect you'll find that saving 57 blank pages should take
on the order of 2-3 seconds, and as you build it up the time will
gradually increase... but hopefully somewhere along the way we'll find
something that causes it to suddenly blow a whole whack of time. You
can also monitor file sizes of each engine along the way and see if
there is anything in particular that causes that to jump unexpectedly
too.
Whether its related to page re-scaling, or a (possibly corrupt)
graphic element on the header, or a related field that's needlessly re-
calculating...
> I did not see any option how to compute an output file name yet. That's
> why I do use AppleScript on this old Mac. I might build a comparable
> solution for Win to rename files, but that's another topic.
The save Records as PDF has 4 checkboxes, one of which is 'specify
output file'. To save it to a programmable name that changes with each
iteration you'll need to use a variable that will be set to:
town::abbreviation & "-" & left(key,5). The variable will need to be
set immediately before saving, in each iteration.
It is like this on both OS X and Windows.
Also, I still do recommend trying it on more modern hardware as well
as under windows, just to gauge the results. I understand you are
targeting a non-profit, and a hardware upgrade may not be in the
cards... but if you get wildly varying performance moving between
platforms that may tell us something useful, may indicate something is
corrupt...
-cheers,
Dave
|
