Performance Fix: Layout / Portal Overload
I am trying to fix an all-in-one layout that was designed for client with 4 or 5 tabs and about 10-12 portals based on different relationships. Each of the portals has its own pre-set sorts for this layout. all of the portals are different paths to the same table in another FM database, but based on different relationships that were built pre-FM 11.
Issue: The whole thing is sluggish. Any change you make to a portal record anywhere on this layout takes a few seconds to commit. Enough to be major drag for users using this layout regularly. In addition, I've been able to confirm that the performance drag also occurs if you are working in a second window making changes on another layout, but also have this layout in the background still.
100% confident I've narrowed the issue down to this layout, and pretty sure it is because of the many portals present. Suspicion is that any single change is updating the record order on all of these separate portal displays. Unstored calcs or fields are not an issue.
So, my first solution was going to be a multi-layout adventure to separate all the portals, but then just use simulated tab headers and nav links to simulate the whole thing as one layout experience for the end user.
New thought today, though: if the problem is not because of the # of portals but the fact that they are all based on separate relationships (designed pre-11), could I take advantage of the filtered portal option, reset all the portals to work from one or two relationships, and the use filters for all the different displays thereof.
Interested in any input here before I go too far experimenting. Not sure either one is a shorter path to re-develop. Main goals are to maintain single layout "experience" for user, but develop new layout architecture that solves the performance issue and is not too demanding to maintain for future layout changes.