Long ElixirLS compile time after upgrading to 0.12

[zwippie]

Environment

• Erlang/OTP 25 [erts-13.1.1] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit:ns]
• Elixir 1.14.1 (compiled with Erlang/OTP 25)
• VSCode ElixirLS version: 0.12.1
• Operating System Version: linux 5.15.0-52-generic

Symptoms

We have a fairly large Phoenix project with over 2000 .ex files and a lot of template files.

After upgrading the ElixirLS extension to 0.12.0, the time ElixirLS takes to compile (dyalizer disabled) our project has skyrocketed from about 2 minutes to over 50 minutes. This is observed from the Output -> ElixirLS tab in VSCode. Lots of it's taking more than 10s warnings (for almost every file in the project) and very high memory usage (over 1.5GB, observed with top).

After downgrading the ElixirLS extension to 0.11 it's down to 2 minutes again.

I've seen the same slowdown on my colleagues machines that run MacOS. I've tried to investigate what causes this but with my limited knowledge of this topic I was unable to find a smoking gun. I realize my information in this issue is very limited. Happy to provide more info if requested!

[VictorGaiva]

It seems that the compilation is not using more than one core at a time. This is causing the compilation to take a long time, and making any changes causes it to restart. So it ends up being compiling most of the time, and almost never works if I'm in a development and making a lot of changes.

[lud]

I'm in the same situation. What took 1~2 minutes takes now over 15. I don't know if that can help, but those long modules are reading from the filesystem to generate a lot of functions using macros.

[shutangyu]

It seems recovered after the tracer disabled, i.e. delete this line :

elixir-ls/apps/language_server/lib/language_server/build.ex

Line 234 in 2984b66

tracers: [Tracer],

which introduced in #724

[lukaszsamson]

It seems recovered after the tracer disabled, i.e. delete this line :

elixir-ls/apps/language_server/lib/language_server/build.ex

Line 234 in 2984b66

tracers: [Tracer],

which introduced in #724

That was the most probable culprit. I wonder what exactly makes the compilation single threaded. Most operations there are through concurrent ets. Only project dir is taken synchronously via genserver call but the result is cached in process dict. Maybe the cache hit ratio is low. Unfortunately I don’t have any easy way of testing that. My biggest codebases are not affected by this issue.

[shutangyu]

files that triggered "it's taking more than 10s" warning are macro heavy files e.g. absinthe's graphql schema definition, phoenix's router

[lukaszsamson]

thanks @shutangyu I can confirm that absinthe schemas are affected. Now I can profile it.

Maybe the cache hit ratio is low

That's not it, hit ratio is high

[shutangyu]

I confirmed that 02d3b2e fixed this issue in my project, thanks @lukaszsamson 👍

[APB9785]

@lukaszsamson I'm still experiencing this issue with the current version. On a large, macro-intensive project, I get extremely long compilation times every time I switch from one branch to another. The whole time I'm maxing out all CPU cores, and I think it will create an overheating problem if I continue.

I'm on an intel macbook running OSX 12.6
versions of VSCode, ElixirLS, elixir, and erlang, are all current