On May 5, 4:33 pm, Martin Trautmann <t-...@[EMAIL PROTECTED]
> wrote:
> On Mon, 5 May 2008 16:02:57 -0700 (PDT), d-42 wrote:
> > > All of this does not explain why sort and print are that slow.
>
> > When you say sort and print are 'slow'. What do you mean
specifically?
>
> As said before, 2 hours compared to > 24 hours
I mean timing for a specfic operation, not the total runtime. How much
longer does a -given- sort take? How much longer does a given print
take? Does it average it 1.2 seconds to sort, and 2.6 seconds generate
a pdf on FM6, but 1.3 seconds to sort, and 12.6 seconds to generate
the PDF on FM9? Or maybe its 12.5 seconds to sort, but 0.5 seconds to
print...
> > You open up a file, and perform a basic sort on a single indexed
field
> > in the table attached to the current layout, and its orders of
> > magnitude slower than it was on FM6? Under what conditions is sorting
> > so much slower?
> No - I use one file, copy certain field contents,
>
> then I go to the main file (external script), enter find mode, paste,
> add some extra values, sort the results, print them to a pdf, rename
> this pdf and exit this external script
>
> to loop to the next record, copy, and continue as above.
Alright, so *is* a process, and worse, no offense, but the script you
describe sounds almost like it was designed to run as poorly as
possible!!
1) Have you tried profiling it at all to isolate what percentage of
time is taken by each step? This can be very instructive. The
profiling will slow it down even further, but the information gained
will tell us where the time is being spent.
If the numbers are low, set up loops for each operation to perform it
1000 times, and then measure the time to do it 1000 times. You'd be
surprised. For example, it takes 15 seconds (on a Core 2 Quad running
at 3GHz ) to copy a text field with 20 characters in it to the clip
board 10,000 times. It takes 1 second to copy that text field to a
local variable 10,000 times.
2) Why use an external script? Why not localize it all in one file.
That tends to make a significant difference to performance in new
versions of FM. (keep the actual data in multiple external files if
you like, but link to them as table occurrences in the file that runs
the script.
3) Don't use copy and paste. That incurs a performance hit. Use a
variable, global variable, or global field depending on the
cir***stances. See above, it can be worse by a factor of ~15. Its
probably not what's killing performance in -your- case, but it
underscores the difference suboptimal choices make.
4) Why are you saving and then renaming the file? FM9 can create the
file with the name you want directly.
5) On a looping script make use of freezewindow to prevent needless
repainting. I usually implment a 'progress bar', that repaints every
few seconds or so (so the application doesn't look hung up). It can
make a gigantic difference.
All that said, We can clearly speed it up some, but I can't say it
will solve your problem. It might well simply be the PDF generation is
the bottleneck or the sorting is the bottleneck and there isn't much
that can be done about it. But I'd want to see some hard evidence of
this before throwing in the towel.
-cheers,
Dave
|
