Portal Threading in FM 15

Today’s release of FileMaker Pro 15 brings a welcome performance boost in the form of in-line portal progress indicators, a.k.a threaded portals. Ian Jempson (@ianjempson) was kind enough to provide me with a test file that he built, and today’s demo file is based on Ian’s work, and shared with his permission. The purpose of the file is, a) to demonstrate portal threading in FM 15, and b) to explore the behavior of variables instantiated via portal filter calcs and/or object visibility.

Demo file: fm15-portal-threading.zip (7.5 Mb)

This might be a good time to observe that this is a “sandbox” demo to facilitate the exploration of FM behaviors, as opposed to one intending to make a specific point or teach a specific lesson. I encourage you to experiment and see what happens.

At any rate, prior to FM 15, if you attempted to navigate to a layout with multiple portals containing lots of related records, there might be a noticeable delay. Now, in FM 15, the layout will be displayed promptly, with progress indicators inside the portals (each running in its own memory thread) until FileMaker is ready to display their contents. And this is not merely a cosmetic trick — you can interact with the layout while the portals are still rendering.

The demo includes a couple of tables containing a million records each…

…and these “related tables” are displayed in a pair of portals via equijoin constant relationships from layouts based on the Test Threading table.

Filtered Portal Layout

On the “portal filtering” layout, the two filter calcs are different: a) to help demonstrate that the portal display threads run independently, and b) out of curiosity to see if there’s any difference in how FM handles the variable instantation.

Note: due to caching, you may need to close and reopen the demo to see some of these behaviors in action.

Once the portals on this layout have completed rendering, click “Refresh Window” and note that both the variables now display 1,000,000. At this point FM has cached all the data, and the variables are maxed out. Scroll the portals, click the buttons, toggle from Browse mode to Find mode and back again… the variables will not change.

Now might be a good time to close the demo, reopen it in FM 14 or earlier, and attempt to return to this layout (in browse mode). It takes a little while doesn’t it?

I asked Ian if he had any comments to add, and he shared the following:

1. Though it sounds obvious, is it worth pointing out that you cannot interact with the portal content until it has rendered fully? This applies both to user interaction and scripted interactions. This was one of the key questions I was wondering about when I started looking at this.

2. I found it interesting that the two variables display different values that reflect where they are in the process of rendering the portals when the layout renders.

3. I also found it interesting that your screenshot (on PC) shows $$p1 = 16789 whereas my Macbook seems to show (on average) $$p1 =~23000. I wonder if this is down to difference in speed of graphics card or underlying computer?

Portal Visibility Layout

Okay, now reopen the demo in FM 15 (or in FM 13 or 14) and this time click “Go to portal visibility layout”.

Here we’re using “Hide Object” rather than a portal filter to instantiate and increment the variables. As in the previous example, two different calculations have been used…

…but the behavior is very different, because in browse mode the layout renders instantly (in all versions of FileMaker), and scrolling a portal will cause its corresponding variable to change. Click “Refresh Window” or use the data viewer to confirm this.

Here are some specific differences:

Portal 3 — $$p3 will always reflect the bottommost visible row.

Portal 4 — $$p4 will increment by 45 (3x the number of visible rows) any time you tickle them… e.g., bounce to the Home screen and back again, or click Refresh Window, or toggle modes.

Visibility Test Layout

Finally, if you’re curious about this item on the home screen…

…it is there for you to experiment with. For example, what happens if you…

• Copy and paste those objects onto the filtered portal layout, and then return to browse mode? Will the $$vt variable update before the portals finish rendering?
• Move the objects off the layout (i.e., to the far right)? Will the $$vt variable update?
• Place the objects on the non-default tab of a tab panel, and then view the layout in browse mode without activating that particular tab… will $$vt update?

Food for thought.