4 ms·
> There's nothing inherent to the LSP protocol or design that causes this problem Even though most of the indexing and intellisense features are done within th
by disposedtrolley 5y ago
> There's nothing inherent to the LSP protocol or design that causes this problem
Even though most of the indexing and intellisense features are done within the language server itself, there'd still be significant overhead in JSON parsing and serialisation right?
The response example for the `textDocument/definition` request [0] shows a very large snippet of JSON considering the information it conveys:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"uri": "file:///p%3A/mseng/VSCode/Playgrounds/cpp/provide.cpp",
"range": {
"start": {
"line": 0,
"character": 4
},
"end": {
"line": 0,
"character": 11
}
}
}
}
[0] https://microsoft.github.io/language-server-protocol/overviews/lsp/overview/ https://microsoft.github.io/language-server-protocol/overvie...
- hnlmorg 5y agoOne of the benefits of the JSON standard being pretty simple is that it makes JSON is pretty efficient to parse. We're not talking ProtoBuf efficient here, but I've easily parsed files containing gigabytes of JSON.
- disposedtrolley 5y agoThat's true, and JSON is probably the best choice as a lowest common denominator given the protocol's intent to be language agnostic. You'd want to implement a language server for language X in X itself, and most languages have mature libraries for working with JSON.