-
Notifications
You must be signed in to change notification settings - Fork 43
Description
This design of this library appears to try to handle one part of the output at a time (e.g. the header, the body, the frozen columns), but this leads to it alternating between modifying the DOM and reading its computed layout. Not only that, but even just while it is building the header or the frozen columns, it is reflowing on every cell. In a table with a mere 175 rows, I found that appendFreezeContent takes an entire 1.2 seconds.
One possible fix for appendFreezeContent is pretty simple: Create all of the "helper" wrappers before the loop. In my local copy I have also incorporated mbrucco's changes which I need, so I can't easily make a PR, but here is the basic idea:
Even with that fix, it's still too slow for resizing:
Looking at the performance shows three big remaining problems:
- shows that calculateHeader has a loop that can probably be similarly optimized.
- shows that appendFreezeContent is still heavily affected by changes in the previous steps. It will be necessary to batch together all reads and all writes separately.
- shows that to get best performance it will be necessary to find a way to trigger a resize without
undo. Deleting and recreating all of those DOM elements simply requires too much layout to be recomputed.
It looks too difficult to fix problems 2 and 3 in the existing code so for now, in my own project I am probably going to try to rewrite the tool (which I suppose will also help me see how it works). But hopefully some improvements can find their way upstream at some point...

