Improving performance of row and column calculators

[wszymanski]

Description

PR https://github.com/handsontable/handsontable/pull/7625 showed that change in number of columns added as offset to calculator may result in performance boost. There is possibility that we can do even more improvements.

Currently, we have linear algorithm which:

• adds from 1 to 12 offset rows for rendering

https://github.com/handsontable/handsontable/blob/a9105ff672ddba8fbdca2524e0a6900a8f8a4f5d/src/tableView.js#L857

• adds from 1 to 6 offset columns for rendering

https://github.com/handsontable/handsontable/blob/a9105ff672ddba8fbdca2524e0a6900a8f8a4f5d/src/tableView.js#L882

This algorithm is basing on:

• number of rendered rows/columns (increasing lastRenderedColumn/lastRenderedRow index increase number of displayed offset elements; when we scroll the number of offset elements is increasing)
• number of renderable rows/columns (the more rows/columns are there, the more scrolling is needed for bigger number of offset elements; bigger scroll steps for bigger offset)

The algorithm is basing on the fact, that the more we scroll, the more we calculate sizes (our calculators always start from 0 to define proper size for all elements which should be displayed). By the way, an offset for fixed elements is established as a constant.

https://github.com/handsontable/handsontable/blob/a9105ff672ddba8fbdca2524e0a6900a8f8a4f5d/src/tableView.js#L843-L845

https://github.com/handsontable/handsontable/blob/a9105ff672ddba8fbdca2524e0a6900a8f8a4f5d/src/tableView.js#L868-L870

It seems that it may be a very big value for most of cases.

Some thoughts

• Changing maximum offset for columns within PR https://github.com/handsontable/handsontable/pull/7625 gave us good effect in test for 1000x1000 elements. However changing columns offset to 4 or row offset to 6 had effect in increasing number of extra loads, but haven't improved performance for "normal" scrolling (without extra load).
• There should be done tests for both big and small datasets and different scroll steps.
• For some, "quite small" dataset there may be no need to use offsets. Maybe all elements could be displayed at start.
• Maybe we should include to our calculation proportion of already rendered to renderable elements.
• Is constant equal to 6 or 12 proper for both big and small datasets? Maybe it should be defined as a value which changes.
• We should remember that performance isn't the only goal, there should be also good UX for scrolling.

TODO

• [ ] Determine whether some non-linear algorithm will be better for calculating number of offset elements
• [ ] Choose the best offset for fixed elements
• [ ] Test solution on big and small datasets with different scroll steps
• [ ] Provide good UX for scrolling

[adrianszymanski89]

Inform Forum