Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance issue of rls on large code base #1410

liufuyang opened this issue Mar 30, 2019 · 5 comments


Copy link

@liufuyang liufuyang commented Mar 30, 2019

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:,
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


This comment has been minimized.

Copy link

@nrc nrc commented Mar 31, 2019

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


This comment has been minimized.

Copy link

@matthiaskrgr matthiaskrgr commented Apr 3, 2019

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.


This comment has been minimized.

Copy link

@alexheretic alexheretic commented Apr 3, 2019

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


This comment has been minimized.

Copy link

@joshlf joshlf commented Apr 6, 2019

I've run into this problem too, and the time is spent on my crate (no 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.

@Xanewok Xanewok added the latency label Apr 7, 2019
@repi repi mentioned this issue Apr 22, 2019
0 of 3 tasks complete

This comment has been minimized.

Copy link

@joIivier joIivier commented Apr 24, 2019

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:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
7 participants
You can’t perform that action at this time.