Log in to create and rate content, and to follow, bookmark, and share content with other members. Not a member? Join Now!

Use "Insert Calculated Result" to concatenate strings! <= Groundbreaking Performance Leap!

Discussion created by mrwatson-gbs on Aug 14, 2018
Latest reply on Aug 21, 2018 by techt

Like • Show 46 Likes46
Comment • 37

OMG! => I just found a super-fast method of concatenating strings in FileMaker!*

With "Insert Calculated Result" (append to variable) FileMaker concatenates strings in linear time O(n).

"Set Variable" on the other hand performs in quadratic time, O(n^2):

Compare:

When concatenating 200 000 strings with "Set Variable" takes >3 minutes,
with "Insert Calculated Result" it is finished in under 7 seconds!

Because:

Try it yourself:

Attached below is a little Benchmarking tool which I used to get these results.

Time to Change!

Please Share and spread the word!

"Happy"& " "& "String"& " "& "Concatenation" & "¶¶" & "MrWatson"

----------------------------

* The original entry was incorrectly posted here as an issue, and reposted here to make it easier to find, share + discuss

----------------------------

2018-08-15 MrW EDIT: Attached new fmBenchMark app, which is now fm16 and fm17 compatible.

Attachments

5 fmBenchMark.zip6.5 MB

Outcomes

37 Replies

philmodjunk Aug 14, 2018 6:46 AM
Given previous tests that showed better performance for modifying data in variables instead of fields, (but not concatenation and using set field), these are surprising results.

It it would be interesting to see how a modified form of your script worked using set field instead of insert compares to your other results.

If a script only concatenates a few strings and does not loop over massive numbers of records, the resulting improvement is unlikely to be observable. I point this out because all of the “insert” script steps have more potentially troubling features than other steps that modify data in a field. Thus, I avoid using them without a compelling reason to do so. Your tests might just identify one more such reason.

”insert” steps, copy, paste, clear all can:
1) fail if the specified target field is removed from the layout.
2) can change layout focus—tripping triggers that run other scripts that might interfere. Not only now, but your future self or a fellow developer might unknowingly interfere with your script by adding such a trigger.

Of course, there are ways to guard against this, but those are steps that I don’t have to take if I don’t use these script steps.
Like • Show 1 Like1
Actions
wimdecorte Aug 14, 2018 7:44 AM
I wonder how much of this ties into the lessons learned from the HyperList v2 about the immutability of variables. Perhaps when variables were added as the target of the 'insert calculated result' the legacy variable behavior was changed?
3 people found this helpful
Like • Show 7 Likes7
Actions
mrwatson-gbs @ philmodjunk on Aug 14, 2018 8:10 AM
I too avoid the "Insert *" into field steps, for the same reasons, UNLESS I am explicitly wanting to trigger a script trigger and not duplicate business logic.

With Target: Variable, however, the same problems do not exist, thus since the advent of "Target: Variable" I use Insert Text Result [ Target: $code ] to embed text or code chunks into scripts without having to escape the text, ... and - starting today - I use Insert Calculated Result for string concatenation.
2 people found this helpful
Like • Show 4 Likes4
Actions
mrwatson-gbs @ wimdecorte on Aug 14, 2018 8:11 AM
wimdecorte wrote:

I wonder how much of this ties into the lessons learned from the HyperList v2 about the immutability of variables. Perhaps when variables were added as the target of the 'insert calculated result' the legacy variable behavior was changed?
Could be, ... but I am surprised that the improved performance has not yet made it to the surface.
Like • Show 1 Like1
Actions
mrwatson-gbs Aug 14, 2018 8:15 AM
For those who have not read the original thread ... here is what I dicovered about the internal workings of Inser Calculated Result:

Technical background:

As far as I know (or at least believed until now) strings in FileMaker are immutable, or in other words new strings are concatenated together from copies of the old strings.

It seems, however, that "Insert Calculated Result" (targeting a variable and with the select option off) appends the text onto the end of the existing variable by resizing the existing string buffer. At least this is what I surmise from the last line of the crash dump:

1 com.filemaker.support.framework 0x000000010a3c3a1c Draco::TextBuffer::ResizeWindow(unsigned int, unsigned short) const + 380

...and above all it explains why Insert Calculated Result works in linear time.

Without the crash, I would probably never have found that out.

Sometimes it is the path, and not just the destination which is important!

MrWatson
14 people found this helpful
Like • Show 12 Likes12
Actions
wimdecorte @ mrwatson-gbs on Aug 14, 2018 8:15 AM
Probably because:
- it is not intuitive to use "insert calculated result" to modify a variable. And it feels like a bit of a workaround
- while the behavior of having the target on the layout has changed over the years, many of us have sort of shunned those old functions because of their erstwhile layout dependency.

So kudos for finding this! It's an important discovery.
4 people found this helpful
Like • Show 9 Likes9
Actions
Fabrice Nordmann Aug 14, 2018 8:37 AM
Thank you so much for sharing.
Like • Show 4 Likes4
Actions
dtcgnet Aug 14, 2018 9:06 AM
I'm using FMA 16. When I run the scripts with the debugger on, I see that the $text variable is set to Get ( ScriptParameter ), but in the file that I downloaded, the scripts run without a parameter, so no values are actually being set. $text was empty, and as a result, $result remained empty.

I modified the scripts so that they used the value in Benchmark::Param as the script parameter. When running 10,000 iterations then, iteration 1 contained "Very long string" and iteration 10,000 contained that 10,000 times.

My results are very similar to yours. In the test with 200,000 iterations, setting the variable took more than 35 times longer than inserting calculated result (165,452 MS versus 4,651 MS). Wow, I'd say...very impressive performance improvement!
3 people found this helpful
Like • Show 2 Likes2
Actions
steve_ssh @ Fabrice Nordmann on Aug 14, 2018 10:42 AM
+1 Thank you. This is really cool. In the past I would sometimes go to great lengths to try to work code around the slowness that you have documented related to Set Variable used in many iterations. The simplicity of the code always suffered as a result. I am looking forward to trying this as a much better alternative. Thanks!!
Like • Show 4 Likes4
Actions
mrwatson-gbs @ dtcgnet on Aug 14, 2018 12:15 PM
I added a quick fix to my original code to make it fm16 compatible, and forgot to pass the parameters...(doh!)... I’ll post a new version soon with a fix (+ support for benchmarking scripts in other files)
4 people found this helpful
Like • Show 3 Likes3
Actions
User16087 Aug 14, 2018 7:09 PM
Hey mrwatson-gbs this is fascinating!
I was so curious that I started playing with things and I found a few additions.

From your notes it seems like the bottleneck is due to Set Variable recreating the variable at every iteration, while ICR reuses them. So I tried to replace the Set Variable for $i with ICR as well (with Select on). Your benchmark file shows that to be 20% faster.
Then I decided to see if the technique we normally use for Loops was even faster, removing the script step altogether and changing the Exit Loop If to
Let( $i = $i + 1 ; $i > $n ) which turns out to be even faster.

So the Let + ICR combination seems to be the best.

Thanks for the find!
7 people found this helpful
Like • Show 3 Likes3
Actions
KevinFrank Aug 14, 2018 8:09 PM
OMG indeed. This is an astounding discovery. Thank you Mr. Watson.
Like • Show 4 Likes4
Actions
KevinFrank @ User16087 on Aug 14, 2018 8:11 PM
Nice!
Like • Show 1 Like1
Actions
davidhead Aug 14, 2018 11:29 PM
Very interesting! Thank you @mrwatson-gbs

For interest, I also tested setting a variable in a Let statement. It was just a little slower than Set Variable. Which makes sense if it operates the same way by recreating the variable.

The following were tested separately to append to a variable, and are presented in order from fastest to slowest:
But that doesn't explain why Salvatore found that replacing the ICR with a Let in Exit Loop If resulted in a faster script. perhaps addition is faster than concatenation.

Because then you can get really tricky and do the whole loop with just one step, like this:
And that is just as slow as the Exit Loop If above.

Cheers, David
Like • Show 3 Likes3
Actions
mrwatson-gbs @ User16087 on Aug 15, 2018 1:07 AM
Hi Salvatore,

Salvatore Colangelo wrote:

… So I tried to replace the Set Variable for $i with ICR as well (with Select on). Your benchmark file shows that to be 20% faster.
Something like?
Insert Calculated Result [ Select ; $i ; $i+1 ]
instead of
Set Field [ $i ; $i + 1 ]
??
I cannot imagine that that alone makes a difference of 20% - that's huge! Are you comparing like with like - have you tested both versions on your own machine, or are you comparing your new results with my old results?
Like • Show 0 Likes0
Actions
User16087 @ mrwatson-gbs on Aug 15, 2018 1:30 AM
Something like?
Insert Calculated Result [ Select ; $i ; $i+1 ]
instead of
Set Field [ $i ; $i + 1 ]
yes ICR instead of Set Variable.
I ran all tests on my machine, rerunning your benchmarks as well (turns out my machine is slower than yours ) and the 20% difference was there.
If you have time, can you confirm/disproof that ?
Like • Show 1 Like1
Actions
hellberg Aug 15, 2018 2:04 AM
This is really interesting. Running the same file in FM16 and FM17 givs me two completely different results? Same computer. Only thing I did was open the file and run "Test All"

FMP 16

FMP 17
Like • Show 3 Likes3
Actions
Paul Jansen @ hellberg on Aug 15, 2018 4:46 AM
Sadly, I have to agree with hellberg My testing also indicates that with v16 both methods take 11-12 seconds for 200000 iterations and with v17 Set Variable takes 182 seconds and Insert Calculated Result 12.5 seconds.

The implication is that rather than ICR being a faster method, we may need to switch to using ICR to maintain the performance we have seen in the past.

PS I also tested older versions and 200000 iterations takes 10-11 seconds in v15 and 13-14 seconds in v14 (clearly I could only test the Set Variable approach)
2 people found this helpful
Like • Show 0 Likes0
Actions
User16087 @ Paul Jansen on Aug 15, 2018 5:06 AM
apjltd , hellberg
I don't know if we're using different versions of the file but like dtcgnet, the one I downloaded is not compatible with v16.

Line 8 of the script "Benchmark this test" uses "specify script by name". So running that script in 16 runs the benchmark with no string. That probably explains the performances you noticed.
Like • Show 1 Like1
Actions
Paul Jansen @ User16087 on Aug 15, 2018 5:24 AM
So a little more digging and whilst the script does have a fix to deal with the lack of Perform Script by Name, it had an empty script parameter which would explain the apparent speedy performance.
I corrected this and ran the 200000 iteration test again using Set Variable and the time was 211 seconds.

I must therefore backtrack and congratulate mrwatson-gbs for finding what does appear to be a genuine performance increase...

Excellent News...
1 person found this helpful
Like • Show 6 Likes6
Actions
hellberg @ Paul Jansen on Aug 15, 2018 6:12 AM
Congratulate mrwatson-gbs, but not to find a performance increase. I would like to congratulate you for finding a serious problem in FileMaker 17 that @Robert_Holsey should look at immediately. It's faster on FMP 16, but not the dramatic increase.

I see the big problem as the worse in speed in FMP 17
Like • Show 1 Like1
Actions
hellberg Aug 15, 2018 7:01 AM
By misstake I found another interesting thing. If FileMaker isn't the front window (running in background while I do other things)

The ones looping 19000 and 20000 is running in background as well as the full graph when using calculated result. This is FMP 17 I haven't tested FMP 16. Setting variable by calculation dosen't seem to bother running in background

3 people found this helpful
Like • Show 1 Like1
Actions
mrwatson-gbs Aug 15, 2018 8:14 AM
Hi folks,

at last more results ...

It seems Insert Text also runs in linear time:

While maybe not as useful as ICR, it may be that Insert Text can still be useful for appending a constant string onto the end of a (large) text - for example in a script based "repeat text n-times" function.
4 people found this helpful
Like • Show 3 Likes3
Actions
mrwatson-gbs Aug 15, 2018 9:38 AM
I've just attached a new fmBenchMark app to the main post.

It is now fm16 and fm17 compatible, and uses the PSBN Module from mrwatson (PSBN = Perform Script By Name)

FYI There is also now a simplfied PSBN17 Module available for use with FileMaker 17.
2 people found this helpful
Like • Show 0 Likes0
Actions
mrwatson-gbs Aug 15, 2018 9:51 AM
OK peeps ... looks like I screwed up with github .. the version seems to be an older version. DOH
Like • Show 0 Likes0
Actions
mrwatson-gbs Aug 15, 2018 10:19 AM
OK ... try again everybody ... new version is uploaded here and on github. I need a break
Like • Show 2 Likes2
Actions
GaryPalmer Aug 16, 2018 2:06 AM
Excellent analysis. We have been doing similar tests over the past year to allow us to upgrade and roll out 16/17 across our users.
Performance trend analysis of newer FileMaker Clients

Our analysis does not exactly relate to the insert calculated result discussed in this feed, but it does show a trend of performance changes between versions of FileMaker Client.

Glad we are not alone in the community in exploring performance changes.
2 people found this helpful
Like • Show 3 Likes3
Actions
MacEasy Aug 16, 2018 6:18 AM
By George, I think you've got it Watson.
A most fine discovery indeed.

‘Having gathered these facts, Watson, I smoked several pipes over them, trying to separate those which were crucial from others which were merely incidental.’
Sherlock Holmes Quote
Like • Show 5 Likes5
Actions
mrwatson-gbs @ MacEasy on Aug 16, 2018 11:24 AM
Lol!

I’m just *Mr* Watson!

it is my wife who has the title Dr. Watson

Both studied the same time - just she got a single doctorate whereas i got two bachelors!

:-)
Like • Show 1 Like1
Actions
MacEasy @ mrwatson-gbs on Aug 16, 2018 11:27 AM
2 is better than 1 right Mr. Watson? Ah maybe not in this case. Glad you enjoyed it, likewise I'm enjoying your trick and shared it with the rest of my team.
Like • Show 1 Like1
Actions
atmospherical Aug 16, 2018 1:05 PM
I was recently doing some brute-force testing that looped through and used the same variables on each pass to collect and compare the results of a new version of a particular script with the old version to ensure the results were the same. I could seed it with a number of iterations to test against random Customer records.

At first the test script would just crash after some number of passes, so I put in an email to myself to get results every 500 passes. I saw almost exactly this same pattern of degradation.

Email 1 - 6:00 after initiation
Email 2 - 12:00 after email 1
Email 3 - 20:00 after 2
Email 4 - 35:00 after 3
... and so on, until (if it didn't crash) it would take hours to get the results email from the next batch of 500.

How I wish I had this thread 2 months ago. Truly an amazing discovery!
2 people found this helpful
Like • Show 3 Likes3
Actions
dansmith65 @ User16087 on Aug 16, 2018 1:43 PM
Awesome find mrwatson-gbs!

I think the comment about using Let in the Exit Loop If statement was miss-understood and I wanted to clarify. I believe Salvatore Colangelo's point was that the script on the right is faster than the one on the left:
Test File: http://permalink.dansmith65.com/filemaker.com/2018/test-loop-overhead.zip
6 people found this helpful
Like • Show 4 Likes4
Actions
jkoester Aug 19, 2018 6:51 AM
Thanks a lot for sharing!!
Like • Show 1 Like1
Actions
user29460 @ User16087 on Aug 19, 2018 9:32 AM
Salvatore Colangelo wrote:

Something like?
Insert Calculated Result [ Select ; $i ; $i+1 ]
instead of
Set Field [ $i ; $i + 1 ]
yes ICR instead of Set Variable.
I ran all tests on my machine, rerunning your benchmarks as well (turns out my machine is slower than yours ) and the 20% difference was there.
If you have time, can you confirm/disproof that ?
I tried a few of these variations - between insert Calculated Result for updating $i as well as doing it in the exit loop if statement with a Let () command.

I found that there was some variation in speed between the result times - but it was not much different than the variation I saw in the test time from just running the original test over and over again.

i.e. hit test, look at the result. hit test again later on, look at the result. It was not usually the same result time and there was some variance.

Other lessons learned using this script for a little bit:
1) Filemaker pretty much didn't touch the disk while the script was running
2) FMPA 17 stopped using more RAM around 4GB - not sure if there is an upper limit
3) FMPA 17 used 1 core for the script processing - this machine is 4Ghz - I'll be curious to test it out on a server machine that is 2.4Ghz and compare.
3 people found this helpful
Like • Show 1 Like1
Actions
TobiasLiebhartKoschierSE Aug 21, 2018 2:30 AM
Thanks a lot for this insight Mr. Watson!
Like • Show 1 Like1
Actions
mrwatson-gbs Aug 21, 2018 1:40 PM
I compared the Replace Field Contents, SetVar and Insert Calculated Result methods for Scrap[ing] the Current Found Set

See the results in >>this comment<<.

[Spoiler: ICR won hands down!]

Enjoy!

MrWatson
1 person found this helpful
Like • Show 0 Likes0
Actions
techt Aug 21, 2018 1:53 PM
Wow, thanks for sharing!
Like • Show 0 Likes0
Actions

Use "Insert Calculated Result" to concatenate strings! <= Groundbreaking Performance Leap!

Attachments

Outcomes

Related Content

Recommended Content

Incoming Links