# Any observed Performance Improvements after upgrading to 19.5.x

**URL:** <https://the.fmsoup.org/t/any-observed-performance-improvements-after-upgrading-to-19-5-x/3000>\
**Category:** Feedback and bug reporting\
**Tags:** filemaker\
**Created:** [July 16, 2022, 3:14pm UTC](https://the.fmsoup.org/t/any-observed-performance-improvements-after-upgrading-to-19-5-x/3000 "2022-07-16T15:14:54Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![FileKraft](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/filekraft/32/1183_2.png) [@FileKraft](https://the.fmsoup.org/u/FileKraft)\
**Post date:** [July 16, 2022, 3:14pm UTC](https://the.fmsoup.org/t/any-observed-performance-improvements-after-upgrading-to-19-5-x/3000/1 "2022-07-16T15:14:54Z")

</div>

Under the hood apparently many code optimizations have been happening as advertised and I am wondering if there are any 'benchmarks' present to verify?

I am running some daily script where batch records are created on the server and I get precisely the same record creation durations etc of all versions since FM18 ...

What subjectively feels faster is interacting within portals but I have no metrics for that.  
Did anyone see anything significantly improved?

---

<div class="post-metadata">

**Author:** ![OliverBarrett](https://avatars.discourse-cdn.com/v4/letter/o/f19dbf/32.png) [@OliverBarrett](https://the.fmsoup.org/u/OliverBarrett)\
**Post date:** [July 16, 2022, 4:40pm UTC](https://the.fmsoup.org/t/any-observed-performance-improvements-after-upgrading-to-19-5-x/3000/2 "2022-07-16T16:40:52Z")

</div>

leider, nicht...

---

<div class="post-metadata">

**Author:** ![planteg](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/planteg/32/627_2.png) [@planteg](https://the.fmsoup.org/u/planteg)\
**Post date:** [July 16, 2022, 6:52pm UTC](https://the.fmsoup.org/t/any-observed-performance-improvements-after-upgrading-to-19-5-x/3000/3 "2022-07-16T18:52:36Z")

</div>

In English, that means ???

---

<div class="post-metadata">

**Author:** ![mipiano](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/mipiano/32/1074_2.png) [@mipiano](https://the.fmsoup.org/u/mipiano)\
**Post date:** [July 16, 2022, 6:56pm UTC](https://the.fmsoup.org/t/any-observed-performance-improvements-after-upgrading-to-19-5-x/3000/4 "2022-07-16T18:56:32Z")

</div>

These German words mean: unfortunately not.

My overall feeling is that FM 19.5 is slightly snappier than earlier versions.

---

<div class="post-metadata">

**Author:** ![weetbicks](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/weetbicks/32/206_2.png) [@weetbicks](https://the.fmsoup.org/u/weetbicks)\
**Post date:** [July 18, 2022, 1:26am UTC](https://the.fmsoup.org/t/any-observed-performance-improvements-after-upgrading-to-19-5-x/3000/5 "2022-07-18T01:26:00Z")

</div>

It is so hard to spot performance improvements in FM these days simply due to the fact the major bottleneck in performance is network bandwidth and latency - something FM can't really do much to improve (short of sending the user field-level data when requested instead of entire records)...

One of the touted improvements is the extension of server-side sorting introduced in 19.... (something..) to include summary field evaluating on server. THis should yield improvement to some solutions that were performing poorly before due to overuse of summary fields on layouts and the like.

However much like server-side sorting, the decision as to whether the server or client will evaluate summaries is entirely out of control over the user. Server will use it's own internal rules based on server load to determine whether it will happen client-side or server-side.

This was an issue for sorting because often times you want to sort on an unstored calculation - such as various dynamic portal sorting techniques - yet without complete control, you cannot use it as unstored calc sorting generally fails when run on server if it is client-specific calculation results.

With the summary fields this is not really an issue, but it would be nice to be able to specify server should always carry out the summarising rather than trying to be too smart and make a load decision - invariably it will always be faster server-side across a large found set regardless of server load.

---

<div class="post-metadata">

**Author:** ![FileKraft](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/filekraft/32/1183_2.png) [@FileKraft](https://the.fmsoup.org/u/FileKraft)\
**Post date:** [July 18, 2022, 1:55am UTC](https://the.fmsoup.org/t/any-observed-performance-improvements-after-upgrading-to-19-5-x/3000/6 "2022-07-18T01:55:22Z")

</div>

great stuff @weetbicks !! - Also very interested in stand-alone performance where there is lots of potential for improvement and optimization. Portals within stand-alone files should be fast and also within fast LAN networks ..

---

<div class="post-metadata">

**Author:** ![Malcolm](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/malcolm/32/196_2.png) [@Malcolm](https://the.fmsoup.org/u/Malcolm)\
**Post date:** [October 31, 2022, 10:12pm UTC](https://the.fmsoup.org/t/any-observed-performance-improvements-after-upgrading-to-19-5-x/3000/7 "2022-10-31T22:12:42Z")

</div>

9 posts were split to a new topic: [Avoid Relationships Using Value Lists](https://the.fmsoup.org/t/avoid-relationships-using-value-lists/3173)
