It's January 24, 2024, the 40th anniversary of Macintosh, and we are announcing Initiative ’24, our endeavor to make FileMaker calculations faster for everyone. To join us in this endeavor, vote for my idea and stay tuned. Read more details below...
The number 24 has a strong symbolic value for 24U and even stronger for myself. It's not only part of our company’s name (although it means "two for" there). I was 24 years old when co-founding 24U, and the company celebrates 24 years in business just next week. This year I simply see 24 all around, wherever I look.
So, being known as the “mad optimizer”, I decided to focus this year on making FileMaker calculations faster for everyone through education and engagement of the FileMaker community. And because I love symbols and challenges, I have set an ambitious goal to make FileMaker calculations run at least 24 times faster by the end of 2024.
However crazy this goal may sound, it is not so unrealistic. See how FileMaker calculations compare to popular scripting languages:
The values shown above are collected from running my reference calculation (see below) for exactly 1 second and counting how many times it gets evaluated in that 1 second. There is one test for math operations and one for text manipulation operations. Each test is then executed 30 times, counting the best result only to eliminate impact of temporary conditions such as the operating system performing other tasks in the background. Here's what the calculation looks like in FileMaker:
I admit my test is not any kind of scientific benchmark, but it was not supposed to be. My intention was to test the operations which I believe are the most commonly used in vast majority of business apps. If you have any suggestion what other formula to add to the test and compare across all these platforms, don't hesitate to let me know.
One reason can definitely be that I am so passionate about FileMaker calculations. You can see that from the various examples I recently created, including PDF Cancas, PDF Barcodes, PDF Pages, PNG Canvas, or PNF Barcodes. I also successfully completed the first 15 challenges of the 2022 Advant of Code solely using FileMaker Calculations. But more important reason is that I simply found it to make a huge sense...
Some people will contradict me that it's more important to focus on the speed of creating, commiting, finding and sorting records. But these operations are really not peforming badly when you try them in a simple database with a simple table, no relationships and no calculations. But the same database will start getting slower as you start adding calculated fields, auto-enter calculations, record-level privileges etc.
Some people will argue that network performance is the key. Yes, client-server apps are still mostly affected by the network latency. FileMaker is still extremely chatty even though it has become much better since its version 6. But it's really not so bad with a starter solutions, until you start adding calculations which, for a single record to show, have to pull tens or hundreds of related records as well.
Claris has already been aware of and optimizing these key operations at lease since the release of FileMaker 12. But how many of you can say your apps have ever become at least twice as fast solely by upgrading to the latest version? Back in 2018 we made one app's layout rendering more than 5 times faster mostly by removing conditional calculations and replacing them with calculated color text fields.
We have been helping our customers make their FileMaker solutions faster since 2007 and became known as experts in hardware integrations and peformance optimizations. And on our journey, we have discovered one important pattern. All our optimization projects have one thing in common. Even though they were not the only factor, we always touched calculations.
And that's not a coincidence, because in today's FileMaker, calculations are everywhere!
How to make it happen?
Making FileMaker calculations faster for everyone cannot be done without Claris making the calculation engine faster. Three years ago I submitted this idea in the Claris Community. This year I would like to convince and help Claris to turn the idea to reality. Here I would like to kindly ask you to help with the former - to convince Claris...
Step 1: Help convince Claris
This is very easy. Just go to my idea in Claris Community and vote for it:
Every vote adds 10 points to the idea and the highest rated idea of all time has received 6.4k points. My idea has 860 points at the time I am writing this, so if only 555 more of you vote for it, adding 5550 more points, it will become the #1 rated idea...
Step 2: Stay tuned and educate yourself
This year, I am planning to share more tips and advice on how to make FileMaker calculations faster than ever before. With or without getting the whole calculation engine faster from Claris, you don't want to miss my announcements. So make sure to subscribe now:
Make sure to sign up even if you are already subscribed to our newsletter. By filling out the subscription form here you will let us know you are particularly interested in FileMaker calculation peformance updates, so that we can send you even updates that we won't be sending to anyone else.
Step 3: Enjoy faster FileMaker apps
To make you able to start today, let me share my first tip right away...
One of the kinds of calculations that can slow your apps down are the "hide object when" calculations. Very often you want to hide several objects, such as fields, at the same time, based on the same condition. It's easy to just select all those objects and specify the hide condition:
But in this case the calculation has to be evaluated over and over again, for every single objects it is attached to. That is 10 times for the example shown in the screenshot above. To make this happen 10 times faster the only thing you have to do is to group the objects together:
Just don't forget to remove the hide calculation from the individual objects first if you already added it. Then you can define the hide condition for the group, which is a single object on the layout:
Now your hide condition needs to be evaluated just once for all the 10 grouped objects. Even though you have not made the calculation itself evaluated 10 times faster, you made it evaluate 10 times less often, which has exactly the same impact.