rgrunber
commented
3 years ago Ideally, we would do this by counting the number of xml/xsd/dtd related documents opened on the client side and simply request a shutdown of the language server when that count reaches 0. There should be a preference enabling this, that is disabled by default.
It might be good to get an idea of what the overhead is for starting the language server from scratch since users choosing this option won't benefit from opening a file and having the server already up. Admittedly, I don't think the overhead is bad at all.
Currently we have a bit of a workaround to terminate the language server process (https://github.com/eclipse/lemminx/pull/1070) due to a regression in the language client API, so I'd prefer to implement such a feature once that is sorted out.
GitMensch
The language server is automatically started by the extension as soon as a file with a handled language-identifier is opened. Within the vscode session only one language server is used.
The issue: often vscode stays open for very long time, but the XML file may be directly closed after it is opened - but the language server will stay open.
I suggest to have a configurable timeout in seconds (0 means never); it would be reset as soon as there is communication with the language server and once reached the language server will be closed, possibly only if the current active editor is not one of the file-types handled.
Note sure if this is common but I have multiple instances of vscode running (different workspaces) and to handle bigger files from time to time I have increased the language server's -Xmx vm args and the language server processes - often only needed for 1 to 3 minutes seem to stay open until I let vscode reload the window.