Re: sorting/printing speed FMP9 vs. FMP6

On May 6, 2:04 pm, Martin Trautmann <t-...@xxxxxxx> wrote:
On Tue, 6 May 2008 13:32:48 -0700 (PDT), d-42 wrote:
2) Why use an external script? Why not localize it all in one file.

This would slow down operations even more. It would complicate backup
schemes. It would slow down data dumps etc.

It would do no such thing.

I misunderstood your answer - I thought your suggestion was to merge all
different tables within a single file.

Hell no. :)

Ok, maybe you are right that a single master file could to the job which
does take all the external data via layouts and related fields.

NO! YOU DO NOT NEED TO WORK VIA RELATED FIELDS!!

That would be slow.

Define a table occurrence in the relationships graph for your external
table, and then define a layout that uses that table occurrence. You
don't need to define a relationship to do this.

Actually, I never tried this approach for this task here. I always
prefered to keep things independently and standalone. But I doubt that
calling the operations one step further away would speed up things. All
my former experience has proven the opposit.

Working on an external table defined as I did above is the same speed
as working on it in its own file. At the same time, a big performance
hit is incurred in FM9 when you hop from window to window. (much
bigger than was incurred in FM6) so not doing it is both possible in
FM9 and highly desireable.

Additionally, hopping around in FM9 does NOT commit records. It did in
FM6. Not committing the records and hopping around, especially between
files, can lead to MASSIVE slowdown in FM7+. If you make changes to a
record and then hop to another window, the record you left behind
still has the record locked and the changes have not be committed.

Switching files, layouts may add a speed penalty. But that's perfectly
minor to the operation itself. Doing a search or a sort on related
records instead of working within this table itself never was faster,
but many times was much, much slower (as indicated e.g. within the
described AND search).

You were doing it on 'related' records. It shouldn't have beeen done
that way.


I don't know whether this malfunction is gone in FMP 9.
But FMP told me it was resorting a certain amount of records, continuing
in negative numbers, even if the only active window had a sorted subset
only. Usually it may have some related records on the layout which might
trigger sorting of related records. I did not find out the logic behind
yet. You don't know this behavior? You never saw sorting on negative
record counts?

Can't say that I have. Although I'm very careful to minimize my use of
sorts because sorting is one of the slowest operations you can do in a
database.

You seem to have taken the least optimal route at multiple points, I
can't help but suspect that maybe, just maybe, your performance hit is
still design related. That its taking longer to sort than it has too,
That your freezewindow is having no positive effect because you are
window hopping, that your applescript is taking far more time than you
think...that maybe there is some goofy summary field calculations that
are dragging your print performance down the tubes...

All of this does sound like minor speed improvements only.

Maybe. Maybe not. You've got a script that takes 12x longer than it
used to. Its worth it to dig deep. Record locking issues alone could
account for it.

I'm also curious, have you tried running your solution on Windows?

No, since Win does not offer AppleScript nor integrated PDF creation.

It needs neither.

Applescript as I said is not needed; you can name your files directly
from within filemaker. And FM9 supports PDF creation under both
Windows and OSX. Its a built in feature of filemaker, not the OS.

Hmmm.... How are you generating your PDFs any way? Are you "printing"
them and using the OSX's 'save as pdf' feature? Or are you using
Filemaker's built in PDF engine accessed via the Filemaker Script
step: "Save Records as PDF" ?

You should try "Save Records as PDF" if you haven't.

That might also be instructive. Also, what mac platform are you
running all this stuff on? G4? G5? Core2Duo?

G4, 800 MHz, 1 1/8 GB RAM, MacOSX 10.4

Thanks. At least we know we have the option of throwing more modern
hardware at the problem if all else fails. By modern standards that's
a pretty slow machine.

-cheers,
Dave
.

Relevant Pages

  • Re: Saving an Internet Explorer STATIC Web Page
    ... CutePDF is also free and works well as a printer (to a PDF ... |>> What good is saving something if it isn't saved (in ... |>> because the page may be several screens long. ...
    (microsoft.public.windowsxp.basics)
  • Re: target="_blank"
    ... I have the same opinion for pdf files. ... window for a page since the user can do it if the user wishes. ... Have you ever heard "Why'd you install MS Office? ...
    (alt.html)
  • Re: OWA (Exch 2003 SP2) and pdf attachments
    ... Now, when I try to open a pdf, I do get a new blank IE window and at the ... directly in OWA. ... restart the Microsoft Exchange System Attendant ...
    (microsoft.public.windows.server.sbs)
  • RiScript 5.02 - wont close either files or windows.
    ... It loaded a trial PDF fine, and I opened the Choices ... I ticked 'Automatically close file when closing window' and Saved, ... RiScript thereafter only showed an empty window, ... error in the download. ...
    (comp.sys.acorn.apps)