Slowness

[jeff-hykin]

@georgewfraser @EvgeniyPeshkov
This issue isn't anything new, it takes a bit for the colors to be updated by the extension. I'm making this issue because I've been thinking more about the tree sitter and I'm not sure where the slowness is coming from. The parser should be much faster than Textmate, and it seems you guys are updating the tree (rather than re-parsing the whole thing on every change).

Do you guys know if it has to do with how often the event occurs (not triggered fast enough), or if it's a decoration issue, or something related to iterating over the nodes?

[jeff-hykin]

I have a potential solution for the theme-colors issue, but it will likely have a computational cost so I'm trying to figure out where performance can be improved and considering if we need to get creative with moving more of the computation inside of Wasm/C++

[georgewfraser]

The setDecorations API is expensive in VSCode. That is why I use textmate for the simple colors, and tree-sitter only for the tricky ones. You can see some detailed profiling in this PR: microsoft/vscode-go#2555

[jeff-hykin]

Hmm do you think Textmate is using something other than setDecorations()?

[matter123]

vscode-textmate produces binary tokens that represent the current color and font style of the text. vscode then maps those tokens to css classes.

[jeff-hykin]

So they're effectively just toggling a css class, and the text nodes in the DOM are being split up based on the textmate scopes? The DOM changes might be expensive but the CSS classes would be a significant advantage over setDecorations

[jeff-hykin]

Looks like VS Code is taking this issue seriously microsoft/vscode#77140

That issue is likely the main blocking issue for the tree-sitter right now