Finer Faster FileMaker Precision: Measuring How Long It Takes

I often like to measure performance, because I am curious if some small change can lead to subtle, or maybe not so subtle, improvements. For the longest time my Swiss Army knife for measuring Claris® FileMaker® performance has been:

Get ( CurrentTimeUTCMilliseconds )

Let’s say you want to measure how long it takes to run a scripted loop. Before you start your loop, add a $_start variable and reference Get ( CurrentTimeUTCMilliseconds ). After the loop, set a $_stop variable with the same Get function.

The threads on my pants – taken with iPhone 14 Pro

Set Variable [ $_start; Get ( CurrentTimeUTCMilliseconds ) ]
<perform operation(s) you want to time>

Set Variable [ $_stop; Get ( CurrentTimeUTCMilliseconds ) ]

Set Variable [ $_time_taken; $_stop - $_start ]

Use this simple formula… [ $_stop ] minus [ $_start ] = total time in milliseconds.

Divide the result by 1,000 and you’ll get the total time in seconds. This has served us well for many years. However, computers keep getting faster. For example, Apple silicon Macs are amazing, and FileMaker performance on these machines is astounding.

Because our machines are so much faster, measuring operations like a script step is harder because the measurement might not be precise enough. With these faster machines, measuring by thousandths of a second, one might see a result like “0.000” which means the measured operation is faster than mere thousandths of a second can distinguish.

FileMaker 19.6 – Now Measuring in millionths

To the rescue is a function, introduced in FileMaker v19.6, called:

Get ( CurrentTimeUTCMicroseconds )

This function can help you measure millionths of a second, aka microseconds: µs.

And I know that HOnza from 24U will also be excited about this new function. Great to check out all the great work he is doing with the FileMaker Performance Lab.

I started to measure how long it takes to go to a different layout using Go To Layout. Then I wondered how much more work it is to go to a layout with the same underlying table occurrence and one where it is a different underlying table occurrence. And I also asked myself what the impact would be if I used New Window and navigated to the layout that way.

Steve on our team suggested we test this in a hosted (FileMaker Server) environment and running Perform Script on Server (PSoS). I broke down the results by where the test was performed and the two different methods, one being Go To Layout and the other being New Window.

Here is the legend, which applies to both charts shown (above and below):

This chart shows New Window when called via PSoS is significantly faster than when run either locally or as a client of a hosted file. It’s also important to point out that going to a new layout with a different underlying table occurrence when using a New Window script step locally is almost a quarter of a second. WOW!

Note: I haven’t tested this using script schedules nor using WebDirect, Data API, or OData. My assumption is these environments would be equal in performance.

Let’s remove the outlier results of Hosted (WAN) and New Window – Locally columns so we can focus on the four shorter columns.

With those really slow values removed, we can see more clearly New Window under PSoS is on the same scale as Go To Layout in any environment. Even opening a new window to a different layout based on a different table occurrence is still only about 2/1000th of a second. And that isn’t even taking into consideration the measurement overhead of using Get ( CurrentTimeUTCMicroseconds ).

In Script Workspace, when choosing Server in the “Show compatible script steps by product” at the top right of the window, one can look at all the steps in a script to see whether they are compatible running in that environment. After choosing Server (since that is where PSoS would run) it shows “(VIRTUAL WINDOW ON WEB)”. So running “virtually” takes less overhead.

New Window [ (VIRTUAL WINDOW ON WEB) ] ; Style: Document ; Using layout: "SUB" (SUB) ]

All this is made possible with the new Get ( CurrentTimeUTCMicroseconds ) function. Otherwise this level of detail would not be visible to us. I’m especially excited to see how this will help test, measure, and optimize FileMaker script transactions. Now that we have this, I can’t wait to see what other innovations the Community discovers using this extra-fine precision.

Simon Brown shared this link with the rest of our team – a great explanation of which things operate at which speeds and getting a perspective on numbers in general.

Anyone for Get ( CurrentTimeUTCNanoseconds )?

Leave a Reply