Open jeff-hykin opened 5 years ago
jeff-hykin
commented
5 years ago 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
commented
5 years ago 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: https://github.com/microsoft/vscode-go/pull/2555
jeff-hykin
commented
5 years ago Hmm do you think Textmate is using something other than setDecorations()?
matter123
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago Looks like VS Code is taking this issue seriously https://github.com/microsoft/vscode/issues/77140
That issue is likely the main blocking issue for the tree-sitter right now
@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?