Can anyone tell if this is still valid in FM18 and also does this also occur if portals are placed on individual tabs/slide controls?
A CRM has complex layouts, some with a dozen or more related tables in portals. These layouts load instantly over LAN and WLAN. Over VPN (less than 5% of LAN bandwidth), it takes 10-20 sec. If bandwidth is small, the quantity of data to load matters and each related table in a portal adds to this.
The portal loads the entire record not only the fields being displayed
FileMaker takes the lazy approach with sliders and tabs: it will only load the records on the displayed tab or slider so it should not impact significantly EXCEPT if there are calculated fields that refer to other tables.
If and how a portal is sorted affects performance.
(I generally do not sort on the relationship level)
This works well: Tasty Sort: Reverse Natural Order – ScaleFM
There are two ways that they impact performance: view rendering and data load.
The first issue is views. The layout renders the objects that are visible. If your portals are on tabs / slide controls that aren’t visible then they aren’t going to impact the view rendering until the panel is displayed.
The second issue is data. Portals raise a lot of issues. Portals are from related records so they will only bring in the fields that are needed to display your portal. If your portal is scrolling this may require loading data for caching. It may already be cached or not. The cached data may not be used, so the pre-caching may not be needed.
If your portal shows a fixed number of rows this issue is reduced.
If your portal is filtered and the filter is not a constant it has to download the entire record set. That’s slow.
If your portal is sorted, it has to download the entire record set. That’s slow.
So, the worst performance is from a scrolling, filtered, sorted portal that has a large record set behind it.
The best performance is from a portal that displays stored data in a fixed set of rows, has no filter, and no sorting.
Thanks everyone for great answers and providing valuable information.
I listened to the Context Podcast Dave Ramsey: FMPerception and FMComparison | The Context Podcast and around 34’20’’ they talk about significant impact if more then one portals are on one layout. I wish they would have talked more in detail about what the mean by significant - it sounded like unexpected or that how you would normally take it into consideration - like a second portal of the same source should just take twice as long - this sounded like there is more to expect. Therefor I am wondering if placing portals into different layouts (back to a method before tab control and slides) would improve layout performance in regards of data entry …
First, sorry for the slow response. Yesterday was a little hectic. So, the tooltip that displays near this indicator on the FMPerception Report Card says, “Wim Decorte has identified this metric as a determiner of layout complexity, and a likely source of performance issues.” My discussions with him suggested that this was a relatively high-level heuristic indicator, suggesting where the most computationally intensive layouts are, and where there may have been a process that is (as Josh Ormond suggested) “gnarly”. I don’t know that I have any personal experience to back that up, so I included the indicator at his request (happily) and referenced him by name in the tooltip.
A number of the other posters on this discussion have provided some great info on ways in which this might manifest. The Report Card is really built around answering the question, “In this huge system, what are the things at which I should maybe take a deeper look”. These points are of interest to Wim… and perhaps others. If you have your own rules about points of interest that are not reflected on the Report Card, I’d love to hear about them.
Thank you for response. What I still wonder is if more then one portal on a layout would cost more performance then the sum of each portal if placed on different layouts? If that would be the case I would remove tab controls …
Thanks again everyone!