# Julia Language Server initialization performance issue

**URL:** <https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446>\
**Category:** New to Julia\
**Tags:** question\
**Created:** [March 25, 2022, 7:11am UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446 "2022-03-25T07:11:24Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![arc](https://avatars.discourse-cdn.com/v4/letter/a/67e7ee/32.png) [@arc](https://discourse.julialang.org/u/arc)\
**Post date:** [March 25, 2022, 7:11am UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446/1 "2022-03-25T07:11:24Z")

</div>

Hello,

I am new to Julia and using neovim in combination with [julia-vim](https://github.com/JuliaEditorSupport/julia-vim) (syntax highlighting) and [coc-julia](https://github.com/fannheyward/coc-julia) (language server).

Having pasted just this small snippet in `main.jl` and started with `nvim main.jl`

```julia
# wait for ide to highlight syntax error
println(1 + 2
 
for x in ARGS; println(x); end
function ()

end

```

, the time to wait for IDE until error highlight has been 43 seconds.

I absolutely fell in love with julia. But this seems to be serious latency. My use case is to utilize julia as a fast-paced shell script replacement.

- Is this just my environment or usual julia startup time?
- Is this fix being worked on ? (in some github issue someone said to work on it actively in 2021, cannot find the github issue anymore)

Thanks for clarifications!

julia version 1.7.2

---

<div class="post-metadata">

**Author:** ![ffevotte](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ffevotte/32/6587_2.png) [@ffevotte](https://discourse.julialang.org/u/ffevotte)\
**Post date:** [March 25, 2022, 8:00am UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446/2 "2022-03-25T08:00:30Z")

</div>

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](https://github.com/fannheyward/coc-julia) seems to indicate that there is at least some support for this _via_ the `julia.CompileLanguageServerSysimg` command.

---

<div class="post-metadata">

**Author:** ![lawless-m](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lawless-m/32/30869_2.png) [@lawless-m](https://discourse.julialang.org/u/lawless-m)\
**Post date:** [March 25, 2022, 8:35am UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446/3 "2022-03-25T08:35:41Z")

</div>

> [@arc](#):
>
> My use case is to utilize julia as a fast-paced shell script replacement.

You’re in the wrong town, buddy 🙂

Julia is a compiled language, every time you run it, you pay the price of compilation.

You can create system images to reduce this, but these end up being 100s of Mb as they contain all the of the Julia runtime.

We call this the “First Time To Plot” problem, or FTTP or more generically FTTX

And is a topic of much discussion and, like your position, angst.

> [@Taking TTFX seriously: Can we make common packages faster to load and use](https://discourse.julialang.org/t/taking-ttfx-seriously-can-we-make-common-packages-faster-to-load-and-use/74949):
>
> So much work has been done to improve julia compilation and remove invalidations. Things really feel a lot snappier to use. But there is still the problem of packages that were written without much thought to startup time, and TTFX - the time-to-first whatever a package does most, is sometimes really slow. Some common problems I see are (reorganised to be in order of importance): Lack of type stability slowing down compilation. Not calling precompile for common methods, or just running them …

---

<div class="post-metadata">

**Author:** ![arc](https://avatars.discourse-cdn.com/v4/letter/a/67e7ee/32.png) [@arc](https://discourse.julialang.org/u/arc)\
**Post date:** [March 25, 2022, 10:06am UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446/4 "2022-03-25T10:06:05Z")

</div>

> [@ffevotte](#):
>
> 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.

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!

> [@ffevotte](#):
>
> The usual way to leverage this is to have a dedicated system image for the Language Server,

Huge. Appreciated!

> [@lawless-m](#):
>
> You’re in the wrong town, buddy

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!

---

<div class="post-metadata">

**Author:** ![oheil](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oheil/32/220745_2.png) [@oheil](https://discourse.julialang.org/u/oheil)\
**Post date:** [March 25, 2022, 11:55am UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446/5 "2022-03-25T11:55:25Z")

</div>

> [@lawless-m](#):
>
> And is a topic of much discussion […]

yes

> [@lawless-m](#):
>
> […] and, like your position, angst.

no

To the OP: Julia [DaemonMode](https://github.com/dmolina/DaemonMode.jl) is the typical solution for Julia TTFX problem and use case as a scripting tool.

---

<div class="post-metadata">

**Author:** ![lawless-m](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lawless-m/32/30869_2.png) [@lawless-m](https://discourse.julialang.org/u/lawless-m)\
**Post date:** [March 25, 2022, 12:14pm UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446/6 "2022-03-25T12:14:08Z")

</div>

Well, it may not be your position, but it causes a lot of angst.

[![](https://global.discourse-cdn.com/julialang/original/3X/1/d/1d5c5567a3f6004a6c9852f4fb8e89eb97fe67be.jpeg "JuliaCon 2019 | What's Bad About Julia | Jeff Bezanson") ](https://www.youtube.com/watch?v=TPuJsgyu87U)

---

<div class="post-metadata">

**Author:** ![oheil](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oheil/32/220745_2.png) [@oheil](https://discourse.julialang.org/u/oheil)\
**Post date:** [March 25, 2022, 12:31pm UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446/7 "2022-03-25T12:31:33Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Henrique\_Becker](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/henrique_becker/32/15443_2.png) [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)\
**Post date:** [March 25, 2022, 2:35pm UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446/8 "2022-03-25T14:35:01Z")

</div>

Well the video is from Bezanson himself and he uses the term _gripes_ (name of a slack channel?). But I think we are getting kinda out of the topic here.

---

<div class="post-metadata">

**Author:** ![arc](https://avatars.discourse-cdn.com/v4/letter/a/67e7ee/32.png) [@arc](https://discourse.julialang.org/u/arc)\
**Post date:** [March 25, 2022, 2:56pm UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446/9 "2022-03-25T14:56:27Z")

</div>

> [@lawless-m](#):
>
> like your position, angst.

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…

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [March 25, 2022, 3:12pm UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446/10 "2022-03-25T15:12:35Z")

</div>

For me, doesn’t seem too bad/slow, seem tolerable:

```julia
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
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:

> [@lawless-m](#):
>
> > [@arc](#):
> >
> > My use case is to utilize julia as a fast-paced shell script replacement.
> 
> You’re in the wrong town, buddy 🙂
> 
> Julia is a compiled language, every time you run it, you pay the price of compilation.

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
$ 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.

---

<div class="post-metadata">

**Author:** ![arc](https://avatars.discourse-cdn.com/v4/letter/a/67e7ee/32.png) [@arc](https://discourse.julialang.org/u/arc)\
**Post date:** [March 25, 2022, 6:41pm UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446/11 "2022-03-25T18:41:57Z")

</div>

Thanks for this elaborate answer @Palli !

I tried your benchmark:

```julia
julia> @time using LanguageServer
  1.867666 seconds (2.64 M allocations: 189.216 MiB, 3.52% gc time, 2.22% compilation time)

julia> @time using LanguageServer
  0.000343 seconds (108 allocations: 9.453 KiB)

```

This seems quite fast.

Instead, if I open a julia `.jl` script file via neovim/coc-julia, for the first ~40 seconds I get following in the bottom bar (_each_ time nvim is restarted):

> Initializing julia 1

After that for ~ 3 sec:

> julia starting async tasks

and a list of loaded modules, which gets processed really quick.

---

<div class="post-metadata">

**Author:** ![ffevotte](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ffevotte/32/6587_2.png) [@ffevotte](https://discourse.julialang.org/u/ffevotte)\
**Post date:** [March 25, 2022, 8:10pm UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446/12 "2022-03-25T20:10:37Z")

</div>

> [@Palli](#):
>
> For me, doesn’t seem too bad/slow, seem tolerable:
> 
> ```julia
> julia> @time using LanguageServer
> 1.044672 seconds (1.76 M allocations: 147.223 MiB)
> 
> ```

Yes, but note that having a fully functional Language Server involves

1. loading the `LanguageServer` & `SymbolServer` modules
2. creating a `LanguageServerInstance`
3. 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).

> [@Palli](#):
>
> 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.

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.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [March 26, 2022, 11:47am UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446/13 "2022-03-26T11:47:52Z")

</div>

> [@arc](#):
>
> Instead, if I open a julia `.jl` script file via neovim/coc-julia, for the first ~40 seconds

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).

> [@ffevotte](#):
>
> 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

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](https://marketplace.visualstudio.com/items?itemName=vscodevim.vim)

---

<div class="post-metadata">

**Author:** ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)\
**Post date:** [March 26, 2022, 3:54pm UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446/14 "2022-03-26T15:54:46Z")

</div>

> [@Palli](#):
>
> Yes, whatever the reason for VS Code being faster, at least it’s fast, so you can consider it rather than vim.

I think it loads in the background while one can start doing things. With that the 30-40s are almost never perceived.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [March 26, 2022, 5:01pm UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446/15 "2022-03-26T17:01:06Z")

</div>

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…

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [March 26, 2022, 5:10pm UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446/16 "2022-03-26T17:10:01Z")

</div>

I suppose you do not want to use Emacs (I’ve deferred trying, people swear by it), which has Julia support.

You could also try spacemacs:

> The best editor is neither Emacs nor Vim, it’s Emacs _and_ Vim!

Emacs was historically been considered to start up slowly (before Julia existed, so not to blame), I don’t what’s it like now of for spacemacs.

[https://develop.spacemacs.org/layers/+lang/julia/README.html](https://develop.spacemacs.org/layers/+lang/julia/README.html)

---

<div class="post-metadata">

**Author:** ![fredrikekre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fredrikekre/32/1688_2.png) [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)\
**Post date:** [March 26, 2022, 6:49pm UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446/17 "2022-03-26T18:49:28Z")

</div>

You can use “my” setup I describe here: [Neovim + LanguageServer.jl - #72 by fredrikekre](https://discourse.julialang.org/t/neovim-languageserver-jl/37286/72). With that I can use the language server functionality instantly.

---

<div class="post-metadata">

**Author:** ![ffevotte](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ffevotte/32/6587_2.png) [@ffevotte](https://discourse.julialang.org/u/ffevotte)\
**Post date:** [March 26, 2022, 6:51pm UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446/18 "2022-03-26T18:51:49Z")

</div>

> [@Palli](#):
>
> I suppose you do not want to use Emacs (I’ve deferred trying, people swear by it), which has Julia support.

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](https://github.com/ffevotte/eglot-jl/tree/ff/sysimage) 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.

  

> [@Palli](#):
>
> I don’t even know exactly what the LanguageServer does for me

If I’m not mistaken, some features provided by the Language Server include:

- linting
- 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)
- inline help

AFAIK, things like debugging or line-by-line code evaluation are handled in VS code by the extension itself, not really the Language Server.

---

<div class="post-metadata">

**Author:** ![arc](https://avatars.discourse-cdn.com/v4/letter/a/67e7ee/32.png) [@arc](https://discourse.julialang.org/u/arc)\
**Post date:** [March 29, 2022, 8:12am UTC](https://discourse.julialang.org/t/julia-language-server-initialization-performance-issue/78446/19 "2022-03-29T08:12:08Z")

</div>

> [@Palli](#):
>
> 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.

Language server offers

- code-completion (like VS Code IntelliSense)
- 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.

> [@Palli](#):
>
> Yes, whatever the reason for VS Code being faster, at least it’s fast, so you can consider it rather than vim.

> [@Palli](#):
>
> I suppose you do not want to use Emacs

No, VS Code and Emacs are out of scope for me.

> [@fredrikekre](#):
>
> You can use “my” setup I describe here: Neovim + LanguageServer.jl - #72 by fredrikekre . With that I can use the language server functionality instantly.

Thanks, I will definitely look into it later. All these customizations currently still feel a bit overwhelming…

> [@ffevotte](#):
>
> 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)

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.

* * *

**Update**

To remove coc-julia as dependency for performance comparison, I tried to manually configure the language server, as proposed [here](https://github.com/neoclide/coc.nvim/wiki/Language-servers#julia). Now following error is shown on CoC console output:

> ERROR: MethodError: no method matching JSONRPC.JSONRPCEndpoint(::Base.PipeEndpoint, ::Base.PipeEndpoint, ::Channel{Any}, ::Channel{Any}, ::Dict{String, Channel{Any}}, ::String, ::Symbol, ::Nothing, ::Nothing)

Surely, I must have done something wrong 😬 .

Is there something to do besides installing `LanguageServer` , `SymbolServer` and `StaticLint` and creating `coc-settings.json`:

```json
{
"languageserver": {
  "julia": {
    "command": "/path/to/bin/julia",
    "args" : ["--startup-file=no", "--history-file=no", "-e",
    "using LanguageServer;\n using Pkg;\n import StaticLint;\n import SymbolServer;\n env_path = dirname(Pkg.Types.Context().env.project_file);\n debug = false;\n server = LanguageServer.LanguageServerInstance(stdin, stdout, debug, env_path, \"\");\n server.runlinter = true;\n run(server);" ],
    "filetypes": ["julia"]
  }
}
}

```

What I don’t get:

> Check out [JuliaEditorSupport/LanguageServer.jl](https://github.com/JuliaEditorSupport/LanguageServer.jl/wiki/Vim-and-Neovim) for more information.

As said, VS Code is not used. In the wiki, they mention LanguageClient-neovim and vim-plug, which aren’t used either.