-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mass decoration registration and disposable is slow #4911
Comments
My guess also goes to the splice needs here, Edit: For reference - I've done an RB tree impl back during the buffer rewrite (which never made it into the core code), maybe this comes handy at some point: https://github.com/jerch/xterm.js/blob/AttributeStorage/src/AttributeStorage.ts Edit2: A balanced tree based impl will perform alot worse for typical insertion/removal at the end. Maybe partitioning of the list (like a skiplist) will already do the job here? |
Yes RB or AVL is probably the fix. I've done both before but it looks like I never bothered porting the RB tree from js to ts yet. https://github.com/gwtw/ts-avl-tree, https://github.com/gwtw/js-data-structures/blob/master/lib/red-black-tree.js
It's still just log n though, the main thing that matters is that it scales well imo |
This can come back after xtermjs/xterm.js#4911 is handled. Fixes #199593
I see if there is anything I can do on the demo to facilitate subsequent verification. 😀 |
@Tyriar How would an easy repro look like? Is it enough to spam tons of decorations all over the lines, or do they need to follow a certain pattern? Which action triggered the toxic removals? Was that just from scrolling off at the top? Because if thats the case, we could prolly lift some burden here by batching the removals with interim "dead keys" on the sorted list and doing a final cleanup copy. Difference would be O(n + m log n) vs. currently O(m*n + m log n) for m elements to be removed from n elements (the m multiplier comes from the splice copy overhead for every single removal in our current bisearch&splice approach, which we have only once with dead keys). |
VS Code issue: microsoft/vscode#199593
Lots of GC happening when registering and disposing many decorations. Here's an example showing and hiding a command guide in VS Code which creates and then disposed ~16k decorations:
https://github.com/Tyriar/xterm.js/blob/1943636f023b0496c2b95aeb31f2d08d7c0e4dce/src/common/services/DecorationService.ts#L41-L60
Some ideas to speed up:
splice
(!) inSortedList
The text was updated successfully, but these errors were encountered: