Optimize datastructure rule evaluation

Datastrucure rule evaluation is significantly slower on certain screens when compared to desktop client.

When changing a child record in HTML5 client it recomputes parent record all the time. Moreover, it seems (not confirmed), siblings of the changing child row are probably reevaluated as well, at least the overall rule evaluation time grows linearly with the number of siblings

In the desktop client, the parent is recomputed only when focus is changed to another child record, or a recompute shortcut is pressed (ctrl+enter). The rule evaluation time is constant, it doesn’t grow with a number of child rows.

The task is to analyze differences between HTML5 client and the Desktop client, propose a solution (possibily including model changes and a change in UI protocol) and implement it.

The analysis has shown the most resources are consumed during evaluation row-level security within getting row states and not within evaluating actual datastructure rules.

Moreover, rowstates (via GetChangesByRow > [GetChangesRecursive] > GetChangeInfo > RowStateProcessor.Invoke) are called as the last action of each SessionStore.UpdateObject() method., which in turn is called several times from SavableSessionStore.UpdateObject(), because it’s called for each entity dependent column (updating it to null).

The actual rowstate call has also an opportunity for optimization. It turned out it triggers same rules many times with the same input data. Firstly, it’s calling entity-level-row-level security rules many times for each column in a table which doesn’t have any row-level security rule itself. An input data for that evaluation is always the same - the current row data, the result is always the same as well. Entity level security rules are also called also when column-level-row-level security is defined for a column, but they don’t match or entity-level-row-level security rules has a higher priotity (their priority number is lower).

Optimalization draft:

  • call rowstates in the final UpdateObject() method, not from UpdateObject() coming from doing dependency field reseting
  • compute and remember a row-level-security result for a security type (read, write, etc) and column which doesn’t have any rule and apply it for all the further columns without any field-level-row-level security rule
  • compute and cache a row-level-security rule result for a current row and use cached value whenever it’s needed again

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.