Page 1 of 1

Performance / # of events

PostPosted: Tue Oct 29, 2013 2:24 am
by CamelCase
I'd be curious to hear what experience people have with the performance of the fmp12 Calendar Pro?
For up to how many events are you using it without performance being an issue (assuming a hosted file and indexed fields)?

Re: Performance / # of events

PostPosted: Tue Oct 29, 2013 9:23 am
by CamelCase
I'll answer myself... Having done some more testing, I must say I'm quite disappointed with performance. Not really all that surprising perhaps, given the heavy use of ExecuteSQL, but in my case, the actual data set of some 40,000 makes the calendar so slow that it's unusable.

If I just keep the last year's worth of appointments (about 5,000 records), performance becomes acceptable again.
I'd hate to have to actually keep a dummy table with duplicate records for the calendar. Does anybody have experience with tweaking the SQL calls to improve performance? Maybe somehow flag records older than n months?

Re: Performance / # of events

PostPosted: Tue Oct 29, 2013 1:44 pm
by jeffalmquist
When the file is on a server, FileMaker's ExecuteSQL function definitely does not scale well with that many records. The problem with ExecuteSQL is that the entire Events table has to be downloaded from the server to the client the first time the query is run. That's going to be brutal with 40,000 records. And unfortunately there's no way to tweak the SQL to improve performance. No matter how the query is structured, the whole table needs to come down.

The good news is that subsequent queries should perform much faster, as the entire Events table is now cached client side. If not, there might be something else going on, as our experience is that things are pretty good after that first hit.

So your idea to move all but the current records into a separate "Archived Events" table is a good one. We've observed that that first query starts to drag when there are about 8,000 records in the table.

HTH... Jeff

Re: Performance / # of events

PostPosted: Wed Oct 30, 2013 1:16 am
by CamelCase
Thanks for the confirmation - always good to know that it's not just me doing something wrong.

Maybe you should sell the calendar with a warning label... ;- )

I really should have known better since I've worked enough with ExecuteSQL to know that it doesn't perform that well. The dirty workaround will be fine in this case since the solution I'm implementing this for already has a very streamlined workflow for creating/editing calendar events, but for more "open" FileMaker solutions, this can be more of a pain.
I don't have the time to test right now, but it would be interesting to compare performance with the FM11 version (or a converted version of it). Do you happen to have any info on what the performance limits are there?

Re: Performance / # of events

PostPosted: Thu Oct 31, 2013 7:11 am
by jeffalmquist
The FM 11 version of the Pro Calendar can start to slow down with a large number of records too, because it uses looping, which poses its own performance challenges. I think the bottom line is that there's only so much that can be done within the constraints of FileMaker until FileMaker provides a better means of doing certain things. Stay tuned.

Re: Performance / # of events

PostPosted: Sat Nov 02, 2013 6:24 am
by CamelCase
Yep, I can't wait for FileMaker Inc to add a "Calendar" type of object! Should be "easy" using the basic web viewer/chart kind of object...
So far my trick with an additional table for current events only works quite nicely. A little bit of work to implement, but still worthwhile using the SeedCode template so I don't have to develop it all from scratch.