3 ms·

That doesn't make sense, they both use tsserver under the hood.

foobarbaz33 1y ago
You could have an lsp server of infinite speed, but that wouldn't help one bit if the bottleneck is how the client deals with the messaging. The specific techniques used to send, receive, and parse JSON could matter.
- hdjrudni 1y ago
  Could, ya, but I'd be pretty impressed and sad if Rust didn't have really good JSON parsers/serializers by now.
  - steveklabnik 1y ago
    It’s had them for a very long time, pre-1.0.
  - adastra22 1y ago
    What do you mean? It has exceptionally good crates for that, and has for more than a decade. Is there something you feel is missing?
    - socksy 1y ago
      Well exactly, I'm pretty sure that's what the GP is getting at — it would be a surprise if Rust didn't have good JSON support. Which it does. So it's unlikely to be the bottleneck.
brundolf 1y ago
I've heard that VSCode gets some special treatment and integrations with the typescript server that go deeper than normal LSP
- CapsAdmin 1y ago
  To expand on this, the vscode editor can do a lot more than what is specified in LSP. You can have custom functions in your language server that is not in spec and have your editor specific plugin call them. I imagine there is a lot of this for typescript. But I'm not sure if this can explain the speed difference..
antmarti 1y ago
As the owner of a somewhat popular language, I checked to see if there's an extension available (there is!) as we publish a language server. One thing I noticed in the implementation is that it looks like it is using stdin/stdout for the JSONRPC inter-process communication, rather than named pipes or sockets. VSCode uses named pipes. I wouldn't be at all surprised if that's a significant bottleneck - I'm about to file a bug. EDIT - commented on the tsserver thread here: https://github.com/zed-industries/zed/issues/18698#issuecomment-3410498828 https://github.com/zed-industries/zed/issues/18698#issuecomm...
rs186 1y ago
VSCode's TypeScript service does not currently use LSP, and many language queries run in the same thread as the extension (or "Extension Host"). That does not necessarily explain the performance difference though

You could have an lsp server of infinite speed, but that wouldn't help one bit if the bottleneck is how the client deals with the messaging. The specific techniques used to send, receive, and parse JSON could matter.

hdjrudni 1y ago
Could, ya, but I'd be pretty impressed and sad if Rust didn't have really good JSON parsers/serializers by now.
- steveklabnik 1y ago
  It’s had them for a very long time, pre-1.0.
- adastra22 1y ago
  What do you mean? It has exceptionally good crates for that, and has for more than a decade. Is there something you feel is missing?
  - socksy 1y ago
    Well exactly, I'm pretty sure that's what the GP is getting at — it would be a surprise if Rust didn't have good JSON support. Which it does. So it's unlikely to be the bottleneck.

brundolf 1y ago

I've heard that VSCode gets some special treatment and integrations with the typescript server that go deeper than normal LSP

CapsAdmin 1y ago
To expand on this, the vscode editor can do a lot more than what is specified in LSP. You can have custom functions in your language server that is not in spec and have your editor specific plugin call them. I imagine there is a lot of this for typescript. But I'm not sure if this can explain the speed difference..

antmarti 1y ago

As the owner of a somewhat popular language, I checked to see if there's an extension available (there is!) as we publish a language server. One thing I noticed in the implementation is that it looks like it is using stdin/stdout for the JSONRPC inter-process communication, rather than named pipes or sockets. VSCode uses named pipes. I wouldn't be at all surprised if that's a significant bottleneck - I'm about to file a bug. EDIT - commented on the tsserver thread here: https://github.com/zed-industries/zed/issues/18698#issuecomment-3410498828 https://github.com/zed-industries/zed/issues/18698#issuecomm...

rs186 1y ago

VSCode's TypeScript service does not currently use LSP, and many language queries run in the same thread as the extension (or "Extension Host"). That does not necessarily explain the performance difference though