Screen with 60 fields in a master record out of 90 fields in the entity
~ 15 child tabs
several row foratting rules
several row level security rules
In the desktop client scrolling and getting rowstates is seamless, a user doesn’t experience any waiting for the data, whereas in html client it takes higher hundreds of millisecond to fetch RowStates, so the whoule experience is shaky, not good.
We need to improve RowStates preformance for the html client.
After profiling, it turned out the most time is spent evaluating child relation security, then action buttons and also column security of master record. Each of these tasks were conducted for all RowStates input row ids. We realized the above evaluation doesn’t have to be conducted for RowStates at lazily loaded screen, because the resulting data isn’t used in the frontend client.
Child relation security, action buttons and column security of a master row is used only when a user standing on a row. Full row states are returned inside a response of MasterRecord call in that case.
Action buttons for the master entity should be evaluated though as I think they are used when displaying multiple-checkboxes buttons when selecting multiple rows.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.