5 ms·

While lsp has brought the best utilities that used to be locked away inside IDEs. I just don't see how you can build upon it when its been shown to struggle pre

While lsp has brought the best utilities that used to be locked away inside IDEs. I just don't see how you can build upon it when its been shown to struggle pretty much since the beginning. JSON is okay if you need a format that is human readable but how did the engineers at microsoft ever think that it was a good choice for interprocess communication?. Most of the work is wasted on decoding the json itself. We should not have to increase the interval between request and batch calls in order to make it usable.

oblio 3y ago
Have you profiled things and have data to show JSON handling is the root of the performance issues?
- shepmaster 3y ago
  Not the person you are replying to, but the JSON performance of Emacs was a well-known thorn in the side for using LSP. Further details... ... from the same source as the top post: https://www.masteringemacs.org/article/speed-up-emacs-libjansson-native-elisp-compilation https://www.masteringemacs.org/article/speed-up-emacs-libjan... ... from lsp-mode: https://emacs-lsp.github.io/lsp-mode/page/performance/#json-native-serializationdeserialization https://emacs-lsp.github.io/lsp-mode/page/performance/#json-...
  - oblio 3y ago
    Ah, ok, I get what you mean, but those are not inherent JSON issues. After all, VS Code & co use the exact same protocol in a speedy fashion. It's Emacs needing to be configured to use faster JSON libraries. The original comment was complaining about JSON as a format itself, and my argument is that unless you need super high performance, JSON is more than enough. And it's not like LSP is passing around GB of data every second, let's be real here :-)
MereInterest 3y ago
LSP as a protocol feels like somebody documented IDE features, then exposed those directly at the protocol level. It's absurd. When last I checked, I could register a function to be used to apply syntax highlighting when the LSP server identifies a change, but you couldn't make any explicit queries against the known parts of the syntax. I wanted to query the LSP server to tell whether the point was currently located within a string, but as far as I could tell, the LSP server couldn't be queried for the syntax type. You can ask for "selection suggestions", you can ask for "semantic tokens" within a specific range, but you cannot ask for the semantic token containing a single specific point.
- db48x 3y ago
  That's exactly what LSP is. Notice that it was invented by Microsoft and it becomes a lot less surprising.
- antoineMoPa 3y ago
  VS Code can achieve much more performant editing with the same server, so there is no excuse for emacs to be slow.
  - MereInterest 3y ago
    My experience is that VS Code has a tremendous amount of input lag, to the point that I need to wait for a search prompt to focus before I can start my query. Emacs, on the other hand, is incredibly responsive, and even when running over a slow SSH connection has properly buffered inputs so I don’t need to wait. Emacs can achieve much more performant editing with the same server, so there’s no excuse for VS Code to be so slow.
    - BaculumMeumEst 3y ago
      VS Code in its current state has no perceptible input latency on modern hardware, easily verifiable. If you invested the time to configure Emacs to mimic VS code's completion- instantaneous fuzzy autocompletion on every keystroke- the GUI would lock up every time autocompletion is engaged, i.e. the entire editor stutters on every keystroke, because the garbage collector is constantly blocking the UI thread. The performance limitations are widely known. It's the reason yyoncho, the creator of LSP-mode, forked Emacs to explore adding multithreading to address the issue [0]. But I can't see this being fixed anytime soon, because there are a fleet of intellectually dishonest zealots on the internet that refuse to acknowledge it's an issue, and will flame anyone who brings it up. As a result, when new users try out Emacs and see that the performance sucks, many of them will instantly uninstall and return to VS code, and the userbase suffers. [0] https://www.reddit.com/r/emacs/comments/ymrkyn/async_nonblocking_jsonrpc_or_lsp_performance/ https://www.reddit.com/r/emacs/comments/ymrkyn/async_nonbloc...
G3rn0ti 3y ago
Treesitter will make LSP servers obsolete at some point I believe. The parser framework also comes with query API you can use for semantic analysis of code — it’s about more than just syntax highlighting. Therefore, with treesitter you should be able to do everything what a language server does for you — inside the editor‘s process.
- konart 3y ago
  Treesitter knows nothing about your code outside of current file, no? Not to mention all of the project dependencies starting for stdlib.
  - G3rn0ti 3y ago
    But a tree sitter mode could parse the related files in the background. That’s exactly what an LSP server does, too.
- noelwelsh 3y ago
  It's only a parser though, right? So it won't know about derived properties of code like types. I think you still need something like LSP because if the language has type inference, which all modern languages do, you need exactly the same type inference algorithm as the compiler otherwise you'll get incorrect inferences in corner cases.
  - G3rn0ti 3y ago
    Most LSP server implementations I've seen are just parsing the source or even stop at just tokenizing it. They don't do anything magical inside the source language (unless a language exposes parsing/compiler internals e.g. like Raku's language server does). So I don't think most LSP servers leverage anything from inside the source language's compiler including performing type inference on your code snippets. Also note: If your code snippet is incomplete because you are just about typing it, this also cannot work in principle. That's exactly why treesitter was invented: To have a robust static parser able to process incomplete or erroneous code. > if the language has type inference, which all modern languages do Well, only if your "modern" language is a statically typed language ... And again: Unless your code is correct and complete, you really can not just run "eval" in your source language and obtain type checking out of the box.

oblio 3y ago

Have you profiled things and have data to show JSON handling is the root of the performance issues?

shepmaster 3y ago
Not the person you are replying to, but the JSON performance of Emacs was a well-known thorn in the side for using LSP. Further details... ... from the same source as the top post: https://www.masteringemacs.org/article/speed-up-emacs-libjansson-native-elisp-compilation https://www.masteringemacs.org/article/speed-up-emacs-libjan... ... from lsp-mode: https://emacs-lsp.github.io/lsp-mode/page/performance/#json-native-serializationdeserialization https://emacs-lsp.github.io/lsp-mode/page/performance/#json-...
- oblio 3y ago
  Ah, ok, I get what you mean, but those are not inherent JSON issues. After all, VS Code & co use the exact same protocol in a speedy fashion. It's Emacs needing to be configured to use faster JSON libraries. The original comment was complaining about JSON as a format itself, and my argument is that unless you need super high performance, JSON is more than enough. And it's not like LSP is passing around GB of data every second, let's be real here :-)

MereInterest 3y ago

LSP as a protocol feels like somebody documented IDE features, then exposed those directly at the protocol level. It's absurd. When last I checked, I could register a function to be used to apply syntax highlighting when the LSP server identifies a change, but you couldn't make any explicit queries against the known parts of the syntax. I wanted to query the LSP server to tell whether the point was currently located within a string, but as far as I could tell, the LSP server couldn't be queried for the syntax type. You can ask for "selection suggestions", you can ask for "semantic tokens" within a specific range, but you cannot ask for the semantic token containing a single specific point.

db48x 3y ago
That's exactly what LSP is. Notice that it was invented by Microsoft and it becomes a lot less surprising.
antoineMoPa 3y ago
VS Code can achieve much more performant editing with the same server, so there is no excuse for emacs to be slow.
- MereInterest 3y ago
  My experience is that VS Code has a tremendous amount of input lag, to the point that I need to wait for a search prompt to focus before I can start my query. Emacs, on the other hand, is incredibly responsive, and even when running over a slow SSH connection has properly buffered inputs so I don’t need to wait. Emacs can achieve much more performant editing with the same server, so there’s no excuse for VS Code to be so slow.
  - BaculumMeumEst 3y ago
    VS Code in its current state has no perceptible input latency on modern hardware, easily verifiable. If you invested the time to configure Emacs to mimic VS code's completion- instantaneous fuzzy autocompletion on every keystroke- the GUI would lock up every time autocompletion is engaged, i.e. the entire editor stutters on every keystroke, because the garbage collector is constantly blocking the UI thread. The performance limitations are widely known. It's the reason yyoncho, the creator of LSP-mode, forked Emacs to explore adding multithreading to address the issue [0]. But I can't see this being fixed anytime soon, because there are a fleet of intellectually dishonest zealots on the internet that refuse to acknowledge it's an issue, and will flame anyone who brings it up. As a result, when new users try out Emacs and see that the performance sucks, many of them will instantly uninstall and return to VS code, and the userbase suffers. [0] https://www.reddit.com/r/emacs/comments/ymrkyn/async_nonblocking_jsonrpc_or_lsp_performance/ https://www.reddit.com/r/emacs/comments/ymrkyn/async_nonbloc...

G3rn0ti 3y ago

Treesitter will make LSP servers obsolete at some point I believe. The parser framework also comes with query API you can use for semantic analysis of code — it’s about more than just syntax highlighting. Therefore, with treesitter you should be able to do everything what a language server does for you — inside the editor‘s process.

konart 3y ago
Treesitter knows nothing about your code outside of current file, no? Not to mention all of the project dependencies starting for stdlib.
- G3rn0ti 3y ago
  But a tree sitter mode could parse the related files in the background. That’s exactly what an LSP server does, too.
noelwelsh 3y ago
It's only a parser though, right? So it won't know about derived properties of code like types. I think you still need something like LSP because if the language has type inference, which all modern languages do, you need exactly the same type inference algorithm as the compiler otherwise you'll get incorrect inferences in corner cases.
- G3rn0ti 3y ago
  Most LSP server implementations I've seen are just parsing the source or even stop at just tokenizing it. They don't do anything magical inside the source language (unless a language exposes parsing/compiler internals e.g. like Raku's language server does). So I don't think most LSP servers leverage anything from inside the source language's compiler including performing type inference on your code snippets. Also note: If your code snippet is incomplete because you are just about typing it, this also cannot work in principle. That's exactly why treesitter was invented: To have a robust static parser able to process incomplete or erroneous code. > if the language has type inference, which all modern languages do Well, only if your "modern" language is a statically typed language ... And again: Unless your code is correct and complete, you really can not just run "eval" in your source language and obtain type checking out of the box.