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?
In English, that means ???
These German words mean: unfortunately not.
My overall feeling is that FM 19.5 is slightly snappier than earlier versions.
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.
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 ..