6 ms·

Speeding up VSCode extensions in 2022

179 points by jayflux 5y ago

duped 5y ago
The tokenization speed issue is already addressed by the language server protocol, which delegates syntax highlighting to language servers via the "semantic tokens" API. Language servers can choose to implement this however they want, and the API allows for incremental additions. I think this is a much better approach that baking tree sitter into VS Code and continuing to use TextMate grammars (or tree sitter specific grammars) to add syntax highlighting. That way it can be applied to any editor that supports LSP integration. Really the world would be a better place for IDEs and text editors if we could just get LSP more standardized, and VS Code's dominance is a decent place to start with it. I'm tired of relying on editor and IDE authors for language support.
- da39a3ee 5y ago
  I believe I've read in various places that the difficulty of doing syntax highlighting fast enough is precisely why it isn't done via LSP. Am I right in thinking that the Semantic Tokens part of the spec (currently) falls short of saying "this is for all your syntax-highlighting needs, please go ahead and implement full-blown syntax highlighters using it" I definitely agree with you that the more we can share between different editors/IDEs the better.
- fcurts 5y ago
  > The tokenization speed issue is already addressed by the language server protocol [...] It's not really addressed. The semantic tokens API is intended for semantic highlighting: > Semantic tokenization allows language servers to provide additional token information based on the language server's knowledge on how to resolve symbols in the context of a project. Abusing the semantic tokens API for syntactic highlighting is slow, unnecessarily complex (why do I need to implement a language server just to do syntactic highlighting?), and only a partial solution (still need a TM grammar, still don't get correct code folding, etc.).
- tsar9x 5y ago
  > I think this is a much better approach that baking tree sitter into VS Code they're implementing both, with tree sitter being 'dumb' version of LSP syntax highlighting: https://github.com/microsoft/vscode-anycode https://github.com/microsoft/vscode-anycode
  - da39a3ee 5y ago
    Oh thanks for that link, that's really interesting. Can someone explain the paragraph below -- I thought "this is an invocation of a function named bar" was what we mean by semantic information: > All features are based on parse trees and there is no semantic information - that means there is no guarantee for correctness. Parse trees allow to identify declarations and usages, like "these lines define a function named foo" or "this is an invocation of a function named bar"
    - fcurts 5y ago
      It uses heuristics to derive semantic information from the parse tree without doing a full semantic analysis.
      - da39a3ee 5y ago
        Is "semantic analysis" in the sense you used it similar to "type checking"?
        fcurts 5y ago
        Semantic analysis is a broader term that (for languages with a type checker) includes type checking. https://cs.lmu.edu/~ray/notes/semanticanalysis/ https://cs.lmu.edu/~ray/notes/semanticanalysis/
  - fcurts 5y ago
    What's "dumb" about Anycode is its semantic features such as "go to definition", code completion, etc., not its syntax highlighting. Alas, Anycode is a separate project.
Veuxdo 5y ago
Can we stop with the "in 2022" headlines?
- altdataseller 5y ago
  It's an SEO thing.
- kervantas 5y ago
  Add "in Rust" to the list too.
  - dr_zoidberg 5y ago
    Is that really bad? I mean, it's telling me the language it's in, so it's a bit of valuable information if I'm looking for articles/posts about something a bit esoteric. Say I wanted to implement algorithm X for which there are few references, well if I read "Implementing Algorithm X in Rust" that's an informative title, whereas maybe if it just were "Implementing Algorithm X" and I then find out upon opnening it that it's in Rust, and maybe I wanted C, Python or MATLAB.
- andai 5y ago
  Anyone else reading this article in 2022?
eyelidlessness 5y ago
Speaking of tree-sitter, I’ve been experimenting with it for a static analysis and codegen idea and… wow it is fast. And super easy to use. I threw together a naive TypeScript type-stripping “compiler”, using the Node bindings so it’s got a couple bottlenecks. It’s within spitting distance of esbuild for a huge (10k loc) real world module (about 80-90ms vs ESBuild’s 20-30ms), and sometimes faster than esbuild for small (50-100 loc) modules. Granted it’s not doing everything esbuild does. But it was a quick experiment with a familiar domain before I go further. Quick as in mostly working within a few hours, and naively optimized for large source content in another hour. The WASM bindings also perform very well (better in some cases), so it can be used anywhere WASM can. Which, it seems to me, means it’s a very good candidate to replace Babel without depending on language-specific tooling like SWC/Rome/Bun.
egg1 5y ago
The more I read about VSCode and Electron apps in general, the more I'm convinced that all this effort is akin to putting lipstick on a pig. Modern CPU designs have all converged on multi-core as the solution to increasing performance, and yet on the software side of things... we've turned all of our desktop applications into Chrome instances running single-threaded event loops. That these extensions are even more poorly optimized is more icing on the cake.
- seumars 5y ago
  Funnily enough the quote on textmate grammars in the article feels quite relevant: >The fact that we now have these complex grammars that end up producing beautiful tokens is more of a testament to the amazing computing power available to us than to the design of the [TextMate] grammar semantics. Amazing computing power available to them indeed.
- jules 5y ago
  Single threading is not the issue. Just 5% of single modern core should be plenty fast enough to run a text editor. You still want multiple threads of course, to avoid blocking the UI for background work, but computers are so fast nowadays that it should still be fast enough even if all threads were run on the same core.
- deleted 5y ago
  [deleted]
- da39a3ee 5y ago
  It looks like VSCode is running many threads (some as separate processes) on my machine. Is what you're saying that it does not provide an API for extensions to schedule work on other threads?
- eyelidlessness 5y ago
  It would be utterly shocking to me if VSCode isn’t using several worker threads for LSP, extensions, etc.
  - 5y ago
jjwiseman 5y ago
One idea for speedups that this article doesn't mention, that I've used very successfully, is splitting an extension into two parts: The Javascript extension that runs in VS Code, and a separate language server[1] written in whatever fast language you desire (without having to compile to WASM). I do this with an extension I develop, and it works very well. Microsoft even provides a library to make this easy, and sample code[2]. In my case the language server is written in Rust, and uses tree-sitter. This combination feels like a super power. (The first version of my extension was written in clojurescript, using the instaparse parser. It quickly became apparent that it was way too slow.) A note on my experience with tree-sitter: It's awesome in every way except one. It's so fast that so far I haven't even bothered with incremental parsing: I can do full parsing on every keystroke; and I know that if I ever need a speed boost, I can add incremental parsing. The API is sane and easy to use. The query API is powerful. But the main weakness of tree-sitter is that the error messages are nearly content-free. The most common error looks like this: "(error)". In my case I can deal with that, but I can imagine that for many purposes that's not sufficient. There's been an issue open for 3 years about improving the error messages[3] but I haven't seen a ton of progress (unless I missed it?). 1. https://microsoft.github.io/language-server-protocol/specification https://microsoft.github.io/language-server-protocol/specifi... 2. https://github.com/microsoft/vscode-extension-samples/tree/main/lsp-sample https://github.com/microsoft/vscode-extension-samples/tree/m... 3. https://github.com/tree-sitter/tree-sitter/issues/255 https://github.com/tree-sitter/tree-sitter/issues/255
- peakaboo 5y ago
  I use treesitter from neovim so it's pretty crazy fast. :)
- capableweb 5y ago
  It seems to be mentioned, unless I misunderstand what you mean. The second-last section in the article begins with this: > If you really need to do some CPU intensive work, it’s now possible to offload some of the workload to a language server. This allows you to implement the bulk of your extension in another language (for instance, writing Rust code and compiling it down to WASM). The section above also mentions tree-sitter.
speedgoose 5y ago
Tree-sitter is interesting. I see that it is used by the Github Copilot extension for VS-Code, which is the slowest on my machine because it somehow contains megabytes of minified javascript and webassembly to call a remote API.
rationalfaith 5y ago
PostThisTooFast 5y ago

179 points by jayflux 5y ago

The tokenization speed issue is already addressed by the language server protocol, which delegates syntax highlighting to language servers via the "semantic tokens" API. Language servers can choose to implement this however they want, and the API allows for incremental additions. I think this is a much better approach that baking tree sitter into VS Code and continuing to use TextMate grammars (or tree sitter specific grammars) to add syntax highlighting. That way it can be applied to any editor that supports LSP integration. Really the world would be a better place for IDEs and text editors if we could just get LSP more standardized, and VS Code's dominance is a decent place to start with it. I'm tired of relying on editor and IDE authors for language support.

da39a3ee 5y ago
I believe I've read in various places that the difficulty of doing syntax highlighting fast enough is precisely why it isn't done via LSP. Am I right in thinking that the Semantic Tokens part of the spec (currently) falls short of saying "this is for all your syntax-highlighting needs, please go ahead and implement full-blown syntax highlighters using it" I definitely agree with you that the more we can share between different editors/IDEs the better.
fcurts 5y ago
> The tokenization speed issue is already addressed by the language server protocol [...] It's not really addressed. The semantic tokens API is intended for semantic highlighting: > Semantic tokenization allows language servers to provide additional token information based on the language server's knowledge on how to resolve symbols in the context of a project. Abusing the semantic tokens API for syntactic highlighting is slow, unnecessarily complex (why do I need to implement a language server just to do syntactic highlighting?), and only a partial solution (still need a TM grammar, still don't get correct code folding, etc.).
tsar9x 5y ago
> I think this is a much better approach that baking tree sitter into VS Code they're implementing both, with tree sitter being 'dumb' version of LSP syntax highlighting: https://github.com/microsoft/vscode-anycode https://github.com/microsoft/vscode-anycode
- da39a3ee 5y ago
  Oh thanks for that link, that's really interesting. Can someone explain the paragraph below -- I thought "this is an invocation of a function named bar" was what we mean by semantic information: > All features are based on parse trees and there is no semantic information - that means there is no guarantee for correctness. Parse trees allow to identify declarations and usages, like "these lines define a function named foo" or "this is an invocation of a function named bar"
  - fcurts 5y ago
    It uses heuristics to derive semantic information from the parse tree without doing a full semantic analysis.
    - da39a3ee 5y ago
      Is "semantic analysis" in the sense you used it similar to "type checking"?
      - fcurts 5y ago
        Semantic analysis is a broader term that (for languages with a type checker) includes type checking. https://cs.lmu.edu/~ray/notes/semanticanalysis/ https://cs.lmu.edu/~ray/notes/semanticanalysis/
- fcurts 5y ago
  What's "dumb" about Anycode is its semantic features such as "go to definition", code completion, etc., not its syntax highlighting. Alas, Anycode is a separate project.

Veuxdo 5y ago

Can we stop with the "in 2022" headlines?

altdataseller 5y ago
It's an SEO thing.
kervantas 5y ago
Add "in Rust" to the list too.
- dr_zoidberg 5y ago
  Is that really bad? I mean, it's telling me the language it's in, so it's a bit of valuable information if I'm looking for articles/posts about something a bit esoteric. Say I wanted to implement algorithm X for which there are few references, well if I read "Implementing Algorithm X in Rust" that's an informative title, whereas maybe if it just were "Implementing Algorithm X" and I then find out upon opnening it that it's in Rust, and maybe I wanted C, Python or MATLAB.
andai 5y ago
Anyone else reading this article in 2022?

eyelidlessness 5y ago

Speaking of tree-sitter, I’ve been experimenting with it for a static analysis and codegen idea and… wow it is fast. And super easy to use. I threw together a naive TypeScript type-stripping “compiler”, using the Node bindings so it’s got a couple bottlenecks. It’s within spitting distance of esbuild for a huge (10k loc) real world module (about 80-90ms vs ESBuild’s 20-30ms), and sometimes faster than esbuild for small (50-100 loc) modules. Granted it’s not doing everything esbuild does. But it was a quick experiment with a familiar domain before I go further. Quick as in mostly working within a few hours, and naively optimized for large source content in another hour. The WASM bindings also perform very well (better in some cases), so it can be used anywhere WASM can. Which, it seems to me, means it’s a very good candidate to replace Babel without depending on language-specific tooling like SWC/Rome/Bun.

egg1 5y ago

The more I read about VSCode and Electron apps in general, the more I'm convinced that all this effort is akin to putting lipstick on a pig. Modern CPU designs have all converged on multi-core as the solution to increasing performance, and yet on the software side of things... we've turned all of our desktop applications into Chrome instances running single-threaded event loops. That these extensions are even more poorly optimized is more icing on the cake.

seumars 5y ago
Funnily enough the quote on textmate grammars in the article feels quite relevant: >The fact that we now have these complex grammars that end up producing beautiful tokens is more of a testament to the amazing computing power available to us than to the design of the [TextMate] grammar semantics. Amazing computing power available to them indeed.
jules 5y ago
Single threading is not the issue. Just 5% of single modern core should be plenty fast enough to run a text editor. You still want multiple threads of course, to avoid blocking the UI for background work, but computers are so fast nowadays that it should still be fast enough even if all threads were run on the same core.
deleted 5y ago
[deleted]
da39a3ee 5y ago
It looks like VSCode is running many threads (some as separate processes) on my machine. Is what you're saying that it does not provide an API for extensions to schedule work on other threads?
eyelidlessness 5y ago
It would be utterly shocking to me if VSCode isn’t using several worker threads for LSP, extensions, etc.
- 5y ago

jjwiseman 5y ago

One idea for speedups that this article doesn't mention, that I've used very successfully, is splitting an extension into two parts: The Javascript extension that runs in VS Code, and a separate language server[1] written in whatever fast language you desire (without having to compile to WASM). I do this with an extension I develop, and it works very well. Microsoft even provides a library to make this easy, and sample code[2]. In my case the language server is written in Rust, and uses tree-sitter. This combination feels like a super power. (The first version of my extension was written in clojurescript, using the instaparse parser. It quickly became apparent that it was way too slow.) A note on my experience with tree-sitter: It's awesome in every way except one. It's so fast that so far I haven't even bothered with incremental parsing: I can do full parsing on every keystroke; and I know that if I ever need a speed boost, I can add incremental parsing. The API is sane and easy to use. The query API is powerful. But the main weakness of tree-sitter is that the error messages are nearly content-free. The most common error looks like this: "(error)". In my case I can deal with that, but I can imagine that for many purposes that's not sufficient. There's been an issue open for 3 years about improving the error messages[3] but I haven't seen a ton of progress (unless I missed it?). 1. https://microsoft.github.io/language-server-protocol/specification https://microsoft.github.io/language-server-protocol/specifi... 2. https://github.com/microsoft/vscode-extension-samples/tree/main/lsp-sample https://github.com/microsoft/vscode-extension-samples/tree/m... 3. https://github.com/tree-sitter/tree-sitter/issues/255 https://github.com/tree-sitter/tree-sitter/issues/255

peakaboo 5y ago
I use treesitter from neovim so it's pretty crazy fast. :)
capableweb 5y ago
It seems to be mentioned, unless I misunderstand what you mean. The second-last section in the article begins with this: > If you really need to do some CPU intensive work, it’s now possible to offload some of the workload to a language server. This allows you to implement the bulk of your extension in another language (for instance, writing Rust code and compiling it down to WASM). The section above also mentions tree-sitter.

speedgoose 5y ago

Tree-sitter is interesting. I see that it is used by the Github Copilot extension for VS-Code, which is the slowest on my machine because it somehow contains megabytes of minified javascript and webassembly to call a remote API.

rationalfaith 5y ago

PostThisTooFast 5y ago