Are you able to specify the setup you are using? For example are you using Filemaker server, what are the technical specifications of this?
There are also methods for denormalizing data in order to speed up summary reports and queries. There are also ways to restructure some queries to improve performance.
You need to specify find criteria where some criteria will be entered in indexed fields and others will not be. Instead of performing a single find, perform a find on just the indexed criteria and then perform a find with the unidnexed fields--using constrain found set to restrict this find to just reducing the found set produced by the first find. This approach is many times faster than performing a single find request.
I do know about thoses techniques, ..... they are all in use :) Right know they do not give a big plus.
But I do not actually want to refer to those tricks, unless I have a million records or more.
jup we use Filemaker Server.
Intel Xeon 3Ghz Dual Core Wolfdale-DP
4 GB Ram.
All over the intenet you read, that filemaker will get performance problems, when you reach a good number of records. And depending on the calculations, the system gets slow sooner or later.
Good questions, but filemaker is slow by design and I my say, designed to be slow :-)
I'm in the process to design an MySQL processor for my needs : export necessary data from FMP to mysql, process them in sql, and get the data back with MySQ<L imports. I think in the future I'll won't use FMP to compute data anymore. I'l use FMP for acquiring the data and display them.
The Philomunk example is very true, in itself it's proof that FM Inc doesn't care at all about performance, the described workaround should be built-in the find function itself, FMP could of course do it itself just like MySQL does.
You can get further speed by making the script executableserver side, but good luck many necesseray steps are not server savvy.
If not use a bot ON the same machine as the server, so there's no network delay. Using that bot I get at least x2 speed compared to same script executed by networker client
ai ai ai
I do not want to use tricks, to make a solution. When you use tricks, you can fall into traps.
I still hope Filemaker will do something about the performance issues.
Good Job FM Inc, see how you push your faithfull customers to other solution by not caring about performance :
- No empty table (I've script that spend minutes to delete a table content)
- No "UPDATE" that works on severa field at once : replace that scan the foundset an only change one value, so if you have 5 record to change FMP scans the foundset 5 times
- Absolute need to have a blank layout in form mode that you go to and freeze the screen onto to not kill the performance. Freeze should be on by default when running doing script (all my scripts are littered by freeze steps), and of course server side savvy. There shouldn't be a hit in performance when running script according to the layout mode.
- Dumb finds (see PhilModJunk example)
- No SQL like syntax accessible and slow as molasse SQL "engine" when you use plug-ins