# R.I.P - GTRR
**URL:** https://the.fmsoup.org/t/r-i-p-gtrr/355
**Category:** Heads-Up!
**Tags:** scripting, slowing
**Created:** [October 2, 2019, 5:26pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355 "2019-10-02T17:26:12Z")
**Posts on this page:** 20
**Page:** 3
### Author:  [@Malcolm](https://the.fmsoup.org/u/Malcolm)
#### Post date: [January 21, 2020, 9:26pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/41 "2020-01-21T21:26:04Z")
Yes, at some point isValid was given extra capabilities and the documentation addresses this scenario specifically. IsValid( ) returns true when "FileMaker Pro Advanced cannot locate (temporarily or permanently) the [related table](https://fmhelp.filemaker.com/help/18/fmp/en/FMP_Help/glossary.html#ww1028042) in which the referenced field is defined".
I forget which version introduced the extra functionality. Prior to that isValid ( )'s functions were limited to testing the validity of data.
---
### Author:  [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)
#### Post date: [January 24, 2020, 11:17am UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/42 "2020-01-24T11:17:37Z")
Omce again, we’ve been involved in an upgrade from FMS15/FMP15 to FMS18/FMPA18 and, just as we had with a v17 equivalent the client immediately complains of it running much slower.
These solutions are more old school, they have been in use for years with loads of unstored calculations, many in wide portals.
We spent 4 hours carrying out like for like tests yesterday, mostly navigating to layouts containing portals and portal scrolling.
Results were:
Navigation - FM18 typically 25% slower than FM15
Portal scrolling - 1st portal height scroll (i.e. clicking in the grey area of the scroll bar) FM18 21% slower than v15
However, second portal scroll FM18 was over 100% slower than v15.
Hence, major structural work is required to old school FileMaker solutions before upgrading. Trouble is, a lot of these are very complex systems, written before many of the tools we rely on now were released. It is very difficult to explain to customers that the newer software is much slower than the old.
I appreciate Claris are optimising for cloud and using caching a lot, but a difficult sell to their existing customer base non-the less.
We hardly use any calculation fields these days, everything is script driven, the above wasn’t one of our solutions, but we still have long-term customers out there with these type of solutions.
---
### Author:  [@EfficientBizz](https://the.fmsoup.org/u/EfficientBizz)
#### Post date: [January 24, 2020, 12:21pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/43 "2020-01-24T12:21:17Z")
Does anybody have some figures of comparison for performance of FMS 15 / 16 / 17 / 18?
btw, did HOnza already join the fmsoup community?
---
### Author:  [@tonywhitelive](https://the.fmsoup.org/u/tonywhitelive)
#### Post date: [January 24, 2020, 12:30pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/44 "2020-01-24T12:30:03Z")
Are the portals sorted either on the relationship level or on the portal level?
If so, this might help...
[https://scalefm.com/2018/12/tasty-sort-reverse-natural-order/](https://scalefm.com/2018/12/tasty-sort-reverse-natural-order/)
---
### Author:  [@jormond](https://the.fmsoup.org/u/jormond)
#### Post date: [January 24, 2020, 12:47pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/45 "2020-01-24T12:47:57Z")
@AndyHibbs is this with StartupRestoration on or off? Many things are slower with 18 as a result of how StartupRestoration works.
We did not notice as much with calcs because we don’t have a lot of complex unstored calcs. Ours users significantly noticed the difference is find performance when we turned SR off.
---
### Author:  [@jormond](https://the.fmsoup.org/u/jormond)
#### Post date: [January 24, 2020, 12:49pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/46 "2020-01-24T12:49:13Z")
@EfficientBizz, @WimDecorte had some numbers comparing 16-18. I’ll see if I can find it, or he will before I get back to my desk.
---
### Author:  [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)
#### Post date: [January 24, 2020, 1:48pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/47 "2020-01-24T13:48:56Z")
Josh
We tried all available settings, startuprestoration on and off, also doubled the cachesize in FMS18 and upped the memory in FMPA18.
None of these made any difference in our particular tests. Almost certainly we will disable the startuprestoration on the production server when we are able to restart the service.
As mentioned above, this is not our solution, we were testing in conjunction with the developer, so have no detailed knowledge of structure.
We tried FMPv16 client, again no change in performance.
Our experience of this happening started with FMS16.
Regards
Andy
---
### Author:  [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)
#### Post date: [January 24, 2020, 3:26pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/48 "2020-01-24T15:26:17Z")
Here we go again, taking this opportunity to switch off startuprestoration:
“Hi Andy, FM processing regarding special search are blocked in find in progress prcessign query \* for more than half and hour
is not normal for a specific request regarding FM- Find , take this time
the problem started with me and the others have same“
Note, English is not this person’s native language
---
### Author:  [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)
#### Post date: [January 24, 2020, 3:39pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/49 "2020-01-24T15:39:11Z")
Requires a full server restart
---
### Author:  [@HOnza](https://the.fmsoup.org/u/HOnza)
#### Post date: [January 24, 2020, 6:42pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/50 "2020-01-24T18:42:56Z")
If you're experiencing slow response from GTRR, the first thing I would look at is top call stats to see what exactly FileMaker Server is doing at that time. GTRR is a complex script step that does many things as part of it behind the scenes, so without having the possibility to debug Draco's code directly, Top Call Stats is the easiest way to get some more info. The other potential source is sniffing the communication with WireShark or similar tool.
You can also simply hire someone to analyze and optimize it for you but I don't want to post advertisement here... 😉
---
### Author:  [@AndyHibbs](https://the.fmsoup.org/u/AndyHibbs)
#### Post date: [January 24, 2020, 7:29pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/51 "2020-01-24T19:29:01Z")
Hi HOnza
Welcome to fmSoup, great to have your input.
The developers know what they have to do, but the hardest thing to understand is the impact of FileMaker Server since v16.
Most customers would expect things to get faster when investing in new hardware and software, not slower, or bringing an existing system to a standstill.
Due to circumstances today I’ve had to recover 3 files as a result of the above using an iPhone and Jump Desktop. You really discover the IOS 13 limitations, but equally impressive this can be achieved on a standard sized phone. But a system that has run fine in FMS15 is now giving major problems in v18.
There are now legacy features in FileMaker that really shouldn’t be used due to whatever changes that have been made in FMS.
---
### Author:  [@EfficientBizz](https://the.fmsoup.org/u/EfficientBizz)
#### Post date: [January 24, 2020, 8:43pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/53 "2020-01-24T20:43:36Z")
Welcome @HOnza.
Nice to have you here.
---
### Author:  [@steve\_ssh](https://the.fmsoup.org/u/steve_ssh)
#### Post date: [January 25, 2020, 3:15am UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/54 "2020-01-25T03:15:29Z")
> [@EfficientBizz](#):
>
> Welcome @HOnza.
> Nice to have you here.
+1.00
---
### Author:  [@ernst](https://the.fmsoup.org/u/ernst)
#### Post date: [February 10, 2020, 8:15am UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/55 "2020-02-10T08:15:38Z")
Hi all,
I use GTRR often with a relation where the left side of the relation is a global field containing a list of record-uids and the right side of the relation the uid field of the table that I want to select in.
What would be the equivalent Find request in such a use case?
---
### Author:  [@jwilling](https://the.fmsoup.org/u/jwilling)
#### Post date: [February 10, 2020, 9:17pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/56 "2020-02-10T21:17:01Z")
Basically add a request for each id. It seems crazy but it's faster than one would expect:
```auto
Set Variable [$ids ; ]
Freeze Window
Enter Find Mode
Go to Layout []
Set Variable [$count ; ValueCount ( $ids )]
Set Variable [$i ; 0]
Loop
Exit Loop If [Let ( $i = $i + 1 ; $i > $count]
New Record/Request
Set Field [Table::UID ; GetValue ( $ids ; $i )]
End Loop
Perform Find
```
---
### Author:  [@jormond](https://the.fmsoup.org/u/jormond)
#### Post date: [February 10, 2020, 9:22pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/57 "2020-02-10T21:22:57Z")
I would be curious to test this ( collect keys, go to layout, perform finds ) vs the global GTRR ( collect keys, drop in global, and then GTRR ). I have a feeling which would be faster, but as I love to repeat wise words I heard years ago ( it was either Wim or Daniel Wood, or both )..."unless it's tracked and measured it's just an opinion".
---
### Author:  [@steve\_ssh](https://the.fmsoup.org/u/steve_ssh)
#### Post date: [February 10, 2020, 9:54pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/58 "2020-02-10T21:54:16Z")
I believe it was in v.16 when I was working on a project where we needed to reproduce a found set where we had a collection of all the primary keys available. I recall that I was eager to try an approach that scripted the creation of the found set with _Perform Find_ and _Extend Found Set_ script steps. It was my hope that using that script could possibly be equally, or more, performant than using a multi-key field, a relationship, and GTRR. As it turns out, GTRR was a bit faster in all the examples I tried.
I believe that I set up the Find based scripts to have a configurable batch size for how many ID's would be added as criteria before executing the Find/Extend step. What I don't recall was whether or not I discovered any sweet spot where performance was best.
It occurred to me to mention this earlier on in this thread, but since that was back in v.16, and thus no longer recent, I held off until now to mention it.
Since I didn't yield any performance gains with my attempt to script the found set creation, I let the scripted find idea sit on the shelf. I haven't ruled it out, however -- I just haven't (yet) had a situation where it made sense to use it.
**EDIT:**
**When I posted this a day or two ago, I neglected to mention solution environment:**
_The above was in the context of a FMS-hosted solution across a LAN, i.e. not a locally running file, nor a WAN setup._
HTH,
-steve
---
### Author:  [@jormond](https://the.fmsoup.org/u/jormond)
#### Post date: [February 10, 2020, 10:27pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/59 "2020-02-10T22:27:04Z")
Great info. It would be interesting to battle-test this on 16-18 and see what difference there is. Since there is obviously some "changes".
---
### Author:  [@Malcolm](https://the.fmsoup.org/u/Malcolm)
#### Post date: [February 10, 2020, 10:39pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/60 "2020-02-10T22:39:08Z")
Back in v9 or v10 it was quite easy to overload GTRR when going to all related records from all records in the current found set. I'm sure that the behaviour has improved but I still script these actions so that they run in batches. This isn't going to be the fastest method but we want to ensure we have 100% reliability before we tune for speed.
---
### Author:  [@Mac](https://the.fmsoup.org/u/Mac)
#### Post date: [February 10, 2020, 11:05pm UTC](https://the.fmsoup.org/t/r-i-p-gtrr/355/61 "2020-02-10T23:05:56Z")
> [@Malcolm](#):
>
> going to all related records from all records in the current found set.
This is the only scenario in which I've personally experienced major slowdowns. But it's also easy to implement and enables searches that clients love and competing products (in our sector) never seem to offer.
[Previous page](https://the.fmsoup.org/t/r-i-p-gtrr/355.md?page=2)
[Next page](https://the.fmsoup.org/t/r-i-p-gtrr/355.md?page=4)