Performance issue of rls on large code base

[liufuyang]

It seems rls runs very slow for some large code base and it makes the development with it somehow unpleasant.

For example, you can try use rls with vscode to develop code on a project such as tikv. I am not sure whether it would be related to which specific code file but here for example I am editing this line on this file:
https://github.com/tikv/tikv/blob/master/src/server/status_server.rs#L45,
where I can remove the ; behind build() to trigger a compile error, and writing it back to see the error goes away.

The timing I got on my machine:

• removing ; to show error, it takes more than 40 second
• adding ; back to see error goes away, it takes around 1 minute and 20 seconds

And during the waiting for rls to give results, I could see from my activity monitor that it seems like a single core was 100% usage all the time.

While if I just use a normal editor, do the same changes and use cargo check to check compile errors, it only takes 10 to 20 seconds for cargo check to finish.

Is there anyway to make rls gives back compile results faster? 🤔

@nrc @jonathandturner

[nrc]

I believe the problem is that in one of TiKV's upstream deps had a sub-optimal build script which forced a rebuild of that dep every time and that means the RLS hits a slow path. I think that is fixed now? Maybe we need to update some deps (worth verifying). That should mean the RLS takes as long as cargo check (although we wait a second or two before starting, I think).

Although this case is a 'problem' with the code (and in general, the RLS is not great for codebases as large as TiKV), we could do better on the RLS side too - we shouldn't rely on users having perfect Cargo setups and we should override Cargo's rebuild heuristics so that we only re-run a build script if that build script changes (if the user wants a rebuild, they can just touch the build script).

[matthiaskrgr]

I also got a performance problem, I wonder if it is related.
I use atom 1.35.1 with ide-rust and language-rust.
When I touch a file and and run cargo check, cargo only needs half a second.
However if I save the file with atom and rls starts refreshing, rls needs ~12 seconds to build everything.
atom says
RLS building: 11s
RLS indexing 382ms
a "cargo build" when modifying a single file only takes 2.4 seconds.

[alexheretic]

Recent nighties have been poor for me too in ide-rust (on Linux). I'm not sure why performance has regressed.

But as a general point you should disable rls config all_targets if you want to more fairly compare with cargo check. Or compare against cargo check --all-targets

[joshlf]

I've run into this problem too, and the time is spent on my crate (no build.rs file), not my dependencies. Here's a trace from Mac's Activity Monitor in case it helps. It gets interesting around line 159; it seems like the bulk of the time is spent in JSON serialization.

[joIivier]

I also have this issue, and saw the JSON generated for my own crate was 8mb large. I saw on the rls documentation that a JSON of 1mb was a performance issue so I'm in trouble as I cannot really blacklist my own project. One solution could be to split the project with a cargo workspace but apparently this is not supported by the current version.
While waiting for a solution to this issue I wrote a tiny vscode extension to run cargo check on file save instead of rls and I got at least error highlight under the second. I link it here if it can help someone else in the meantime but this is only a stop-gap until this issue is resolved: https://github.com/joIivier/cargolint