@ffevotte has contributed tooling to make using LanguageServer.jl compiled by PackageCompiler simple with eglot. I would appreciate if anyone who is interested in the significantly alleviated startup time this gives (from 15 seconds down to less than 1) could test out his branch before I merge to master so that we can work out any bugs.
non-Jedi:master ← ffevotte:ff/sysimage
opened 08:08PM - 15 May 20 UTC
The following PR introduces features helping compile and use custom system image… s for LanguageServer and SymbolServer. The expected benefits are reduced start-up times for the language server. On my (old-ish) machine, start-up times are reduced from 20 seconds to less than 2. On a newer machine where I also tested this, times went from 15 seconds down to less than 1.
The idea is the following:
- `eglot-jl.jl` looks at the `EGLOT_JL_TEST` environment variable; when it is set, the server is configured to read from an IOBuffer that sends it an `exit` instruction as soon as it is able to process requests. This allows `eglot-jl.jl` to be used as a `precompile_execution_file` that exercises the (language) server before gracefully exiting.
- a `compile.jl` script automates the generation of a system image, named after the julia version (and having the relevant extension depending on the OS).
This is what the first commit in this PR introduces, alongside with instructions in `README.org` explaining how to compile the system image, and set `eglot-jl-julia-args` to use it.
The second commit goes a step further: it automates the search for a suitable system image at server startup, in order to use it if one is found.
- a first call to julia allows getting the version number. This involves something like 0.1s additional latency before the server is run, which I think is acceptable but is nevertheless quite a large amount of time for such an insignificant-looking task
- a suitable system image is looked for, based on the version number; if one is found, the corresponding `--sysimage` command-line switch is generated. If not, nothing happens; no system image is used, so users who have not generated any system image will not be impacted by this.
- the whole process handling system images can be deactivated using a new `eglot-jl-enable-sysimage` customizable option. This allows users to opt out of the system, even if they have previously generated a system image (for example in case it would become stale for some reason). It also completely removes the julia version overhead.
Additionally, a new autoloaded command allows running the system image generation script from within emacs. The same command could be used to re-generate a system image if the previous one caused problems for any reason.
This is documented in `README.org`. I've tested this with Julia 1.3 and 1.4, on Windows and Linux, without encountering any problem (I don't have access to a Mac).
I know you were reluctant to handle system images in `eglot-jl`, and were (rightfully) especially concerned about possible ways that a system image would become obsolete. I tried making this implementation as robust as possible, but I might very well have overlooked something. So please do not hesitate to tell me if something bothers you with this proposal.
5 Likes