I’m an emacs user, so I don’t have experience with coc-julia in particular. But I’d say that what you’re seeing here is not really the julia startup time (not sure what you mean exactly by that, though), but rather the startup time of the language server. The language server will indeed usually take a long time to start, although the situation has noticeably improved recently, and 43s seems a bit high for Julia 1.7.2.
The usual way to leverage this is to have a dedicated system image for the Language Server, but this probably has to be handled by your IDE when it launches the server. So I would try and look whether coc-julia can handle system images. A cursory look at its README seems to indicate that there is at least some support for this via the julia.CompileLanguageServerSysimg command.
Yes, indeed this is rather language server startup time, sorry for not being specific enough.
The whole environment additionally runs in a virtual machine, which might explain higher initialization time.
Thanks for the info, that startup time still takes relatively long!
More specifically: julia CLI is snappy and only takes 1-2 sec to compile and report syntax error.
So this is not a matter of just compile time, rather language server initializiation with regards to coc-jula (as answered by @ffevotte ).
See it as compliment to the language that I am still on board
Also thanks for explaining TTFX and giving the link!
Ok, I don’t want to watch the whole video now. I just thought, “angst” must be way to much for this technical issue (admitted grave technical issue, at least for some). I see “we worry about it a lot”, but this is still far away of “angst”. So, I still don’t see the “angst”, but I am fine if this is just me.
Just noticed this part. Angst is definitely the wrong term, at least for me.
I started to learn julia yesterday, without having background knowledge of it. Conciseness, expressiveness and practical functional programming features impressed me.
Waiting 40 seconds for a 5-liner code each IDE start was the first thing I found to be frustrating/irritating. I did neither experience this delay with other language servers (Python, TypeScript, Java).
@oheil DaemonMode.jl looks really interesting! I need some time to figure all this out and get bit more knowledge…
For me, doesn’t seem too bad/slow, seem tolerable:
julia> @time using LanguageServer
1.044672 seconds (1.76 M allocations: 147.223 MiB)
Note, before that, just after installin it, that it was much slower (typical for all packages):
julia> @time using LanguageServer
[ Info: Precompiling LanguageServer [2b0e0bc5-e4fd-59b4-8912-456d1b03d8d7]
61.587472 seconds (1.86 M allocations: 152.937 MiB, 0.15% gc time)
Maybe you did see time more like the latter, but not the “Precompiling” message, as it was hidden from you (for some reason)? I.e. you wouldn’t experience such slowness again. I believe the LanguageServer.jl is also used by VS Code Julia extension. And VS Code starts up for me in about 3 sec. so not really a problem.
I also use vim regularly (but w/o any support/extension for Julia). It should be/has much faster startup than only VS Code, without any extensions. And it seems the overhead should be the same in seconds, with extension.
Since you’re a new Julia user:
That’s simplified advice, yes Julia compiles, but as you saw about it precompiles (not fully), all dependencies. Many dependencies load quickly, in like 0.01 sec. or less, while others can easily take 5 sec. or more, because of all sorts of (avoidable, mostly) issues.
Python ASLO compiles packages and stores so not needed again. But as with Julia, I believe the compilation of the main script is not stored, so it will be compiled each time (unless you use DeamonMode.jl).
Julia WAS designed to be a shell-scripting replacement, and while it IS in some ways better than bash or Python (regarding code quality/security), both bash and Python have slightly faster startup, and faster compilation, because Julia optimizes more. Thus you are faster at runtime (for long-running scripts), i.e. if the runtime is long enough it eats the startup overhead.
And not all scripts are speed-critical anyway.
Some options to be aware of:
$ julia -O0 --compile=min --startup-file=no
julia> @time using LanguageServer
1.066555 seconds (1.77 M allocations: 147.824 MiB, 4.54% gc time)
It didn’t really help in this case, you can use either of the first, good to be aware of, especially for scripts. And you might not have a startup Julia file, but if you do, the third option is good (I wish it were the default…), to get rid of that extra overhead.
Note the LanguageServer.jl at least is only meant for IED/editor support, so for the actual scripts you wouldn’t use it so not suffer from that overhead.
Yes, but note that having a fully functional Language Server involves
loading the LanguageServer & SymbolServer modules
creating a LanguageServerInstance
running the server
While the first two steps are very fast in recent versions, the last step still involves some latency (in the sense that the server is not able to answer any request before some compilation is done). This is relatively hard to benchmark, because the server itself is an endless loop waiting for requests coming from a client (which, at least in the real-world intended use case, is a separate process). But it looks like it takes around 8s on my machine for the server to answer the first request. Not a huge deal, but still a noticeable delay (but nowhere near the 43s reported here, which still seem to be high for a recent version of the server running on a recent version of julia).
Indeed, LanguageServer.jl is also used by the VS code extension. AFAIU, there is some magic performed to reduce startup times in the context of VS code, but I don’t know much about this and am not able to discuss this much further. However, my experience with eglot-jl (which is one of the ways to integrate LanguageServer.jl within Emacs) tells me that there still is some latency involved when starting the Language Server (although I should mention, again, that this used to be the root cause of many gripes about eglot-jl, but incredible progress has been made in this area). I know of only one way to reduce this latency, which involves system images, but it is relatively hard to implement in a completely foolproof way, especially when you don’t control the precise Julia version that your users will end up having on their system.
So it seems to be every single time, not just a one time (e.g. precompile) cost. That’s of course non-ideal. I just wanted to make sure not a misunderstanding, which it wasn’t. And clarify a bit for scripting (which is immune to this, while having its, smaller startup issues).
Yes, whatever the reason for VS Code being faster, at least it’s fast, so you can consider it rather than vim. Note, vim keybindings are available, for some compatibility, but that’s yet another (non-Julia specific) extension to use: Vim - Visual Studio Marketplace
I don’t even know exactly what the LanguageServer does for me, I suppose then, that if I trigger its use (too early, like by what debugging?) I could have to wait. Seems it never happened for me. I also suppose this background loading could also be implemented for vim…
To be clear, IMO the situation should not be much better in Emacs than Vim w.r.t. the startup time of the Language Server. There is an experimental eglot-jl branch that implements the creation and use of a custom sysimage for the Language Server, which cuts down the LS startup time to almost nothing. But this branch is not merged (yet) since I haven’t found any completely foolproof way to perform the whole process in a plug & play way while supporting several Julia versions.
If I’m not mistaken, some features provided by the Language Server include:
code navigation (things like “jumping” between definition and uses of a given function or variable) → this requires building an index of the code of all packages in the environment, which is cached but might take a little while the first time you develop in a given project
code refactoring (e.g. renaming of variables)
AFAIK, things like debugging or line-by-line code evaluation are handled in VS code by the extension itself, not really the Language Server.
code navigation (think e.g. of “go to references”)
error diagnostics, like syntax error highlighting.
Hence until after ~ 40 seconds each vim start, it can only be used as plain text editor for .jl files.
As workaround I keep nvim open by putting it as background job, when doing other things.
No, VS Code and Emacs are out of scope for me.
Thanks, I will definitely look into it later. All these customizations currently still feel a bit overwhelming…
Just installed neovim, nodejs, julia-vim and coc-julia on a fresh Fedora machine/VM.
Startup time: ~36sec.
I guess, additional extensions previously might have occupied some extra time.
Still being quite a long startup for default configuration, without UI feedback.
To remove coc-julia as dependency for performance comparison, I tried to manually configure the language server, as proposed here. Now following error is shown on CoC console output: