Why is FileMaker 12 slow?

May 31, 2012

Speedy Snail

A lot has been written and said since FileMaker 12 was released about its speed, compared to FileMaker 11. Emotions left aside, if I was supposed to compile all the recent findings into a single brief message, I would say that some people find FileMaker 12 slower than FileMaker 11 while others experience improved performance after upgrading to FileMaker 12. Check it out yourself in my LinkedIn poll.

Diving more into detail, most people seem to experience speed up in the back end and slowdown in the frontend. This experience is actually in line with FileMaker’s original focus for this version upgrade: to make the server faster and to make the front end nicer. However the people experiencing slowdown may take this as a serious issue for their solutions, let me elaborate a bit about why the users’ experience is so varying, whether it is good or bad, and what is the best way to handle the situation.

Why don’t we have the same experience?

So why does the new version of FileMaker appear slower to some users and faster to others? Well, simply because we don’t use the product the same way. The difference is natural and it actually happens with every version upgrade of FileMaker, just like with every other software product. We can even see this happen in the  world of physical products, such as cars, as well.

To explain what exactly is happening here, imagine that FileMaker Pro version X has just 3 features A, B, and C. To make it even simpler, let’s assume each of these features is represented by a script step that takes specific amount of time to execute. Then FileMaker Pro version Y is released, addressing a popular demand and introducing a new feature D. Since the feature A was very popular as well but was not very fast in the version X, FileMaker decided to optimize it, so the feature A is now much faster in version Y. Unfortunately, the new feature D would interfere with the feature C in some situations, so additional code had to be added to the feature C, which made it slower. So this is how FileMaker Pro version Y now compares to version X :

Time spent executing the feature once
FM Version X FM Version Y
Feature A 100 msec 50 msec
Feature B 200 msec 190 msec
Feature C 30 msec 90 msec
Feature D N/A 300 msec

This is what an upgrade of any software typically looks like. Some features get optimized, some new features get added, and some features get slower because of the extra overhead of the new features.

As I mentioned above, it works the same in the real world as well. New car model may have new features, such as aircondition, parking sensors, airbags etc. The cost of these features is heavier car and increased power consumption. On the other side, more efficient engine compensates the increased weight and power consumption. Depending on how all these features are balanced, the new model can consume less or more fuel than its precedessor. It also depends on how these features are used. That’s where we get back to how these changes in a new version of FileMaker Pro affect our solutions.

Is it good or bad?

I hear you saying: “It depends.” And you’re right. It depends on how your solution actually utilizes the individual features.

It’s natural that some features become slower. It’s the natural cost of new features being added. And if you know a bit of programming you know that every new feature adds some overhead even if it is never used. We want new features, don’t we?

We cannot avoid the extra overhead, so the question we should be asking is: When is the slowdown acceptable and when does it start to be unacceptable?

You might thing that it setting some reasonable percentage, such as 30% slowdown, would be a good rule. But that would be a huge mistake. In some cases even 10% slowdown can kill a specific solution, while even 1000% slowdown may be acceptable in another one. How’s that possible?

It’s all about bottlenecks

If you have seen my Finding the Bottleneck video you know that there is a single point in your solution that has the largest impact on it’s overall performance. The point is called the bottleneck. Depending on how you define the term, you can say that bottleneck can be only one or that there may be a primary one and a few secondary. The key is to understand that performance of the bottleneck affects the overall performance of the whole solution tremendously, while speed of anything else is rarely noticeable even if it changes a lot.

To make it a bit more complicated, it’s also important to understand that FileMaker Pro, the operating system, the hardware, and even the user, all are integral parts of a specific solution. Replacing any part may affect what actually is the solution’s bottleneck.

So let’s assume we are running on the same hardware, same environment, don’t change a single line of code and the only change we do is upgrade FileMaker from version X to version Y. Let’s see how the above shown version upgrade affects two different solutions. For the purpose of this modeling, I will identify one specific feature as the bottleneck of each solution by specifying how many times per average user session the feature is  used and how much time in total is spent executing the feature.

Solution 1 Solution 2
Feat. # of uses FM X time FM Y time # of uses FM X time FM Y time
A 120k 3h20m 1h40m 12k 20 min 10 min
B 6k 20 min 19 min 12k 40 min 38 min
C 60k 30 min 90 min 60k 30 min 90 min
D not used not used
total time cut from 4 hours
to 3 hours 29 minutes
total time up from 1 hour 30 minutes
to 2 hours 18 minutes

As you can see from the table above, my hypothetical version upgrade has significantly different impact on the two model solutions. In the first case, just upgrading to the version Y would save 30 minutes on average 4-hour user session, while in the case of model Solution 2 upgrading would result in the Feature C becoming the solution’s new bottleneck and the whole solution being nearly twice as slow.

How far is this from what people experience with the recent FileMaker 12 upgrade?

Based on my experience there is no specific feature being bottleneck in most cases. Every solution is different and very specific and it’s nearly impossible to predict the performance impact of a new FileMaker version without knowing each solution’s bottleneck. Actually, it’s extremely likely that every FileMaker upgrade will make at least some solutions slower. Even if the new version has all features faster and only one slower in comparison to the previous version, there still can be a solution whose bottleneck is just this one feature, and then this solution will get slower by the upgrade.

Is there any hope at all?

Does this mean that with every new version some portion of the user base has to stick with the previous version or simply quit using FileMaker? No!

One thing always plays for you. New hardware is likely to make everything faster, so at some point, even solutions that are now slower under FileMaker 12 will get back to its current FM 11 speed after some time. Specifically with CSS rendering it’s likely to happen as we are already seeing hardware-accellerated HTML/CSS rendering in mobile device.  So even if you just wait and don’t do anything, the time will come when you will be able to upgrade both hardware and FileMaker.

Then there is the chance that FileMaker will make things better for you even on the current hardware. As I mentioned, naturally every upgrade and update contains not only new features, but also optimizations of the existing features. So if you’re affected by one of the features that most other users are affected by, you’re likely to win FileMaker’s attention and focus. You can even increase your chance by reporting your issue in the FileMaker’s Support Forum. Just don’t forget that the purpose of the report should be telling FileMaker that you also experience the issue and helping them to reproduce the problem so that they can fix it. Emotions, however understandable, do not help in the support forum at all.

Lastly, there is a chance that you can help yourself. If your solution’s speed is significantly affected by the upgrade then I bet it’s because the changes in FileMaker 12 has touched your solution’s bottleneck. If you successfully identify the bottleneck, you will be able to optimize it, even though the FileMaker features being used there are slower in FM 12. Well, you will actually benefit from optimizing the bottleneck even if you don’t upgrade…

The best way to deal with this

Whether you like it or not, FileMaker can hardly predict how their upgraded products will affect performance of all solutions out there. We are not used to tell FileMaker what our solutions’ bottlenecks are. Sadly, we are not even used to find that out for ourselves. What we are used to is asking FileMaker for new features, such as modern layout design tools. So it’s natural that major version upgrades mostly address these feature requests and minor updates address the issues we have (and report) with our existing solutions after upgrading.

User apjltd wrote this in response to the FileMaker 12 speed issues & test results thread at the FileMaker Developer Community website:

My current approach to 12 is to use it for new projects and test test test before considering conversion of any existing database solutions.  None of my v11 clients will get converted until 12v2 and most will probably wait until the next full release unless I really need one of the new features.

I’m really excited by the rebuilt layout engine (design surface) It’s long overdue, but brings the UI into the 21st century.  Sure it has some teething problems, but I’ve got at least 20 years left in business so I’m prepared to take a long view.

And that’s my advice. It’s actually the same advice I am giving to my clients since I started working with FileMaker Pro back in 1992:

  1. Test copies of your solutions with the new version and report any issues
  2. Wait at least until v2 or v3 revision is available before upgrading any key solutions currently working
  3. Use the new version for new projects, so that you learn it quickly and stay in line with the evolution

If you need to expand your or your client’s license you can always ask for downgrade when necessary. And since it’s much easier to avoid or work around issues brought by the new version when creating a new solution, it’s rarely dangerous or inefficient to use the newest version for new stuff. Plus you get all the new possibilities allowed by the new features.

This year FileMaker DevCon‘s slogan is “Major Breakthrough”. I think the major breakthrough has already started two years ago with the release of iPad. The IT world as we know it is definitely over and I am glad that FileMaker has the dare to make the hard decisions necessary to get prepared for the new era. I wish you all, my fellow FileMaker developers, the same dare, great patience, best luck, open minds, and a lot of joy on this path of discovery.

{ 4 comments… read them below or add one }

Darren Burgess August 7, 2012 at 6:35 am

Thanks HOnza for your great work on leading the community regarding the performance issue. In one current solution I am working on, I believe the bottle neck is a combination of too much conditional formatting and some triggers that are firing a few extra times. I need to look at ways of gaining better control of the triggers and optimizing the conditional formatting.


HOnza August 7, 2012 at 6:55 am

Darren, I would suggest you first measure all the conditional formattings and script triggers? Sure, it may be all of them adding up, but you may also find out that one or few of them are more harmful than the rest.
If you don§t mind, let me know what you discover. I am curious.

daryl January 10, 2013 at 12:42 pm

Have you re-run this test in 12v3 yet?


HOnza February 16, 2013 at 4:09 pm

I am not sure what test you’re referring to. I have used only hypothetical solutions as examples in this article to explain why there always are solutions that get faster and others that get slower when switching to a new version of FileMaker Pro.
If you mean the poll I published on LinkedIn then yes, I published another one for 12v3 – it’s available at http://lnkd.in/AAuedG.

Cancel reply

Leave a Comment