Microsoft used to maintain a log inspector [1] which you could use to see the chatter between the server and client, and there was a _lot_ of chatter with a _lot_ of JSON.
[0] https://microsoft.github.io/language-server-protocol/overvie...
[1] https://github.com/microsoft/language-server-protocol-inspec...
If someone has all their CPU fans, etc. spinning up when opening a big monorepo it's probably just aggressive indexing inside the LSP server they're using. Almost certainly it's an optimization trade-off made by the LSP server author, trying to balance the common case of people typically opening smaller repos and assuming they immediately want search, etc. to be fast and ready.
There's nothing inherent to the LSP protocol or design that causes this problem--someone could build a better LSP server designed to handle large monorepos by deferring indexing, etc. until absolutely needed (but potentially with some tradeoffs like searching inside a subunit being delayed until its used). It's the same basic problem git faced with enormous repos over time slowing down and all the hacks/workarounds people have bolted on to try to limit how much of the monorepo state needs to be available at any moment.
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
}
}
}
}
Goland doesn't have any of these issues. Whatever they did, it works.