Unreasonably poor editor performance when RLS is connected

[joepie91]

I'm currently following this blog series, and I'm experiencing severe performance issues in Atom while doing so; every file modification (key press, undo, etc.) takes anywhere between 100ms and 500ms to occur, and the editor hangs in the meantime. This is making my editor absolutely unusable.

I've isolated the problem to ide-rust, specifically when it's connected to an RLS instance with an rls.toml specifying an alternate target; I've tested the following scenarios:

• RLS connected, rls.toml specified: Performance is unusably poor.
• RLS disconnected (eg. repeatedly killed and restart limit reached): Performance is fine.
• rls.toml removed: Performance is fine.
• Editing a non-Rust project: Performance is fine.

I've uploaded an archive here of the project in the exact state in which it causes performance issues. There's also a profiler dump of the performance issues.

I'm currently using Atom 1.31.2 x64, on NixOS 18.03.

(The rls.toml is necessary to keep RLS from complaining about conflicts with std, since this is a no_std project.)

[alexheretic]

This strongly seems like an upstream RLS thing, perhaps raise an issue there to get more eyes on this.

[joepie91]

That seems odd - surely a delay on the RLS side, even if that's where the root of the issue is, shouldn't lead to editor delays? I would expect all I/O to be asynchronous, and therefore it should never block waiting for a child process to do something.

[alexheretic]

Yes, though heavy usage may still cause such issues. rls.toml is purely config for rls and doesn't influence the client behaviour. Editing it causes ide-rust to send a message to rls with new config that's all.

I think the no_std issues can also be worked around by disabling all_targets, can you try this rls.toml instead:

all_targets = false

[maxbrunsfeld]

@joepie91 I tried to load that profile dump in Atom and got an error message:

Failed to find browser main thread in trace, some timeline features may be unavailable

Did you record that profile using the Chrome dev tools in Atom?

[crone123]

Hello,
In my case, with this extension, I need to restart Atom very frequently because of this:
https://smglive.org/nextcloud/index.php/s/D6j7qR2H2gGYy9T

Atom takes all my memory, and makes my computer swap on my SSD !
Just after killing atom is on the 3rd screenshot.

Without using rust-ide, I don't have any problems.
But it seem to be only when the IDE Rust try to check errors with RLS, the ram increase but never decrease.
I have already contacted the atom support, and they said the problem is in this extension.

Can you fix this? It's a huge memory leak.

Thank you !

[alexheretic]

@crone123 RLS is still suffering memory usage issues in Linux, see rust-lang/rls#1188, rust-lang/rust#56980. I've noticed this seems to cause atom itself to also consume lots of memory (obviously compounding the issue) and currently I have no idea why.

[crone123]

It's really strange, because the rls process takes about 200MB of memory, but atom....today for me it takes...26GB of memory (14GB on RAM + 12GB on SWAP)....

[alexheretic]

It's really strange, because the rls process takes about 200MB of memory, but atom....today for me it takes...26GB of memory (14GB on RAM + 12GB on SWAP)....

Wow that's crazy. How quickly does it get to that after ctrl shift F5 restarting atom?

[crone123]

Sometimes after 1h, but now just in 5 minutes, I have no choice but I need to disable rust-ide, it's not possible to use it.
I work on multiple rust projects, with more or less dependencies.

I saw that, more dependencies the project have, the faster it is to take all the memory.

When I work on very small project with only standard lib, I can work some hours without problems (but it's laggy).

But, if the project have some dependencies, it's become not usable. And building a project without dependencies not really productive...

[crone123]

I saw another thing, if I compile from the terminal with cargo, atom become laggy, and generally it make atom to consume more memory than when I use it.... very strange... but it's really a problem...

[enzious]

I'm having this issue on my laptop and desktop as well. The desktop has 32GB of RAM and it will eat all of it until my computer crashes (No swap)

[alexheretic]

Unfortunately the latest 1.35 rls release seems to be even worse for memory usage.

[crone123]

But it's strange because the rls process takes about 130 - 200MB of RAM, it's really Atom who takes really a lot a memory.
That's why I wonder if it's really RLS, or the Rust IDE, or a special issue in Atom for Linux?

Technically, if the problem occurs in RLS, we might see RLS to takes a lot of memory, but it's not the case.

Problem in Atom garbage collector? Or in Rust IDE Memory Management?

[alexheretic]

Yes I think you're probably right that the Atom memory usage is not connected to the rls memory problems directly.

Now I'm getting consistent 8GB atom memory usage I've been experimenting a little. A heap snapshot using the atom dev tools only accounts for ~150MB.

I wondered if it's something to do with rustc/rls generating loads of files in the ./target directory. I set my rls.toml to include

target_dir = "/home/alex/tmp/rls"

deleted the old ./target/rls directory & restarted everything. This means the target data will now be outside the project dir.

Now atom is down to under 200MB, and this seems to help quite a lot. But I'm not totally sure yet, I'll continue to monitor this. Maybe you could also try this workaround and see if it helps your use case?

[crone123]

It is possible, because for example, in my case, compiling the project from the terminal will freeze atom. (only with Rust IDE enabled) during the compile time.
And, for the same project, on a new computer, it doesn't take a maximum of memory immediately, but, after some time, it takes huge memory size really fast.

So, it's possible that is a cause.

In my case, for some weeks, the only way I have to work is to disable Rust IDE.
Now I develop without Rust IDE, with the hope of a fix in the future.

[jspaulsen]

Yes I think you're probably right that the Atom memory usage is not connected to the rls memory problems directly.

Now I'm getting consistent 8GB atom memory usage I've been experimenting a little. A heap snapshot using the atom dev tools only accounts for ~150MB.

I wondered if it's something to do with rustc/rls generating loads of files in the ./target directory. I set my rls.toml to include

target_dir = "/home/alex/tmp/rls"

deleted the old ./target/rls directory & restarted everything. This means the target data will now be outside the project dir.

Now atom is down to under 200MB, and this seems to help quite a lot. But I'm not totally sure yet, I'll continue to monitor this. Maybe you could also try this workaround and see if it helps your use case?

@alexheretic I'm able to recreate this behavior. Thank for you for finding a work-around! This issue was making atom nearly unusable, requiring frequent restarts.

[alexheretic]

I can confirm that there is a serious performance problem caused by rls/rustc ./target/rls file system data generation & the Atom file watching APIs.

A more general workaround is to switch to Emulated with Atom events File System Watcher in Atom core config.

[crone123]

Ok, but why there is an issue only when IDE Rust is enabled?

If I run "cargo build" Atom will freeze, but only if IDE Rust is enabled, not if it's not the case.
Will IDE Rust try to analyse each new file in the project folder without distinction? (supposition only)

[alexheretic]

The memory problem I'm seeing is there when ide-rust is disabled.

If I disable ide-rust and restart, then open a terminal and run rls --cli for my project I get the same large memory usage and poor performance from Atom.

This does makes sense as, if I'm reading the atom code correctly, the atom file watchers are setup & active at project startup.

When enabled ide-rust is running rls, which of course contributes to the issue. You can try the same test and maybe we can rule out ide-rust itself.

[alexheretic]

One thing I can't really explain is the memory issue isn't reproducible by running cargo directly, even in a different target dir. I can run cargo builds multiple times without causes atom memory issues. But when I run rls --cli there it is.

Quite strange since really rls is basically just running cargo itself.

[crone123]

But, does rls generate more files than just cargo?

It must a difference between the 2 that produce a bug in Atom FS Watcher.

I confirm was never produce this issue for me, except maybe when IDE Rust is running, I can see Atom freezing each time I run cargo, but maybe it's related to the fact RLS is running, and Atom takes already a huge amount of memory....

I will try running RLS without rust ide to see if I can see the issue.

[crone123]

I can confirm that problem is Atom related.

Without Rust IDE, if you run rls --cli atom will immediately leak memory, and got high CPU Usage.

Today when I work, atom uses approximately 250MB or RAM, and just a few seconds after starting rls --cli, atom takes 700MB, and grow until rls is closed.

[alexheretic]

I've reproduced it using minimal atom/nsfw code & raised atom/nsfw#7 & Axosoft/nsfw#72.

As that code is platform specific, this may only be affecting Linux users.

[sunjay]

Just to add a data point, I'm on Linux and I see Atom start to use > 10 GB of memory regularly on relatively small ~1000 LOC projects.

$ rustc --version --verbose
rustc 1.35.0 (3c235d560 2019-05-20)
binary: rustc
commit-hash: 3c235d5600393dfe6c36eeed34042efad8d4f26e
commit-date: 2019-05-20
host: x86_64-unknown-linux-gnu
release: 1.35.0
LLVM version: 8.0

Relatively few dependencies too:

[dependencies]
vek = "0.9"
image = "0.21"
tobj = "0.1"

[dev-dependencies]
assert_approx_eq = "1.1"

[profile.dev]
opt-level = 3

I'm going to try removing the target/rls directory to see what happens. I'm also going to try updating Atom since I just realized I'm on 1.36.1 and Atom is already on 1.38.2 😮

[sunjay]

Oof. Just over the last 2 hours of working I've hit 13.7 GB of RAM.

[alexheretic]

@sunjay the nsfw Linux leak has been fixed but I'm not sure it's in an atom release yet, did you try the workaround #104 (comment) ?

[sunjay]

I tested it for a few days and the workaround does indeed address the memory leak. Thanks!

[alexheretic]

ide-rust has moved to using rust-analyzer instead of RLS.

I'll close this issue for now, please reopen if this still applies to the new stack.