FileMaker Memory Bug?

For all my time with FileMaker, there's this peculiar aspect of one's learning journey where small bits and pieces of information come to you in odd ways. You either happen to stumble upon them, or you're told about them through the grapevine. Not from the company itself.

While most large companies are often busy with the business of improving their software, their outbound communications about certain things aren't always prompt or highly detailed. Personally, I love what Claris has been doing with FileMaker communication in the last few years. It's a night and day situation compared to just 5 years ago. There are, however, situations where you have to hear about a particular feature from a close parter like Soliant. Even Claris themselves didn't publicize the fact that FileMaker Server 19.5 supported Perform Script on Server - running on Server - via a flag named SupportNestedPSOS. Go ahead, search for it in Google. You won't find it anywhere on any of the Claris sites (at least as of the posting this article).

Which brings me to technical issues and possible bugs. Unless you frequent the Claris Community forums, it's unlikely you've heard about the 9 year issue of FileMaker being a total hog when it comes to memory allocation for certain functions. All credit goes to Alex Zueiv for this long running discovery. At this stage, it may be known and intentional by Claris, but it certainly is an eye opener. So much so that I decided to make this video to increase awareness. Like you, I like my software to run as efficiently as possible and workarounds, hacks, what have you, I'm going to take advantage of the findings because with software, that's just what you do. You optimized until it's as good as it can be!

Comments

Frankly, I don't know for 19 and the new Edge Engine for WebViewers. This is still 18 stuff...
Here's the catch: Display a WebViewer of any WebSite on a Layout. WebSites that use a lot of JS show the effect faster. Now with a WebPage on display just flip to another record, using the Rolodex... very simple. It seems that if the other Record builds the WebViewer again (based on a gField does not help). All the Memory that the IE uses leaks towards FileMakers Memory allocation.
What does help a little bit is to set the WebViewer to "" prior to changing the record. The MBS Plug-In does have an extra Command for this: MBS("WebView.ClearBrowserSession")

Hi, did you test if the memory bug was solved in the 2023 release?
It seems it was solved
Many thanks