Stream: t-compiler/wg-rls-2.0

Topic: rust-analyzer is fast :-(


matklad (Jun 12 2019 at 17:32, on Zulip):

Logical continuation of [rust-analyzer is slow :-(](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/rust-analyzer.20is.20slow.20.3A-().

After my recent optimizations, I can no longer reproduce slow on enter. However other folks can! I expect that this is due to my laptop being to fast (it's a relatively beefy machine).

I'd love to add "slow connection mode" to rust-analyzer, which restricts the amount of CPU it can use. How should I implement this thing?

Ideally, I'd love to do some syscall from within rust-analyzer procces, like "self-limit me to at most 30% CPU". In theory, I can use cgroups and/or thread affinity for that. However, I've looked into this today, and I don't think I can easily write this thing: existing cgroups bindings are pretty low-level and require me to know more about cgroups than I want at this moment. And the set_affinity syscall works on per-thread basis.

Do folks have any suggestions for self-restricting CPU in as little lines of code as possible? Should I .... just exec myself using some Linux command-line utility?

Laurențiu Nicola (Jun 12 2019 at 17:37, on Zulip):

you can also set the nice to a larger value, but I'm not sure it's a good idea

Laurențiu Nicola (Jun 12 2019 at 17:37, on Zulip):

if you throttle RA, you'll end up waiting more for it to return the results

Laurențiu Nicola (Jun 12 2019 at 17:39, on Zulip):

maybe a better approach is to wait a little before processing the client requests? like that old "wait 250ms before showing completions" trick

matklad (Jun 12 2019 at 17:41, on Zulip):

Hm, I think CPU throttling is exactly what I want here? Like, I want to expose existing slow bits of code, and I don't know where they are, so I don't know where to insert the sleep calls

Laurențiu Nicola (Jun 12 2019 at 17:42, on Zulip):

Ah, got it. I thought you wanted to slow down RA to help people with slower computers, but it's for testing.

matklad (Jun 12 2019 at 17:43, on Zulip):

yeah, I want to slow RA to help people with fast computers :D

Laurențiu Nicola (Jun 12 2019 at 17:44, on Zulip):

https://scoutapm.com/blog/restricting-process-cpu-usage-using-nice-cpulimit-and-cgroups

Laurențiu Nicola (Jun 12 2019 at 17:44, on Zulip):

cpulimit?

Laurențiu Nicola (Jun 12 2019 at 17:45, on Zulip):

it even works for processes that are already running

Laurențiu Nicola (Jun 12 2019 at 17:45, on Zulip):

It does this by sending SIGSTOP and SIGCONT signals to the process.

Laurențiu Nicola (Jun 12 2019 at 17:45, on Zulip):

:joy_cat:

matklad (Jun 12 2019 at 17:47, on Zulip):

yeah, I figure cgroups are a better approach today. And I also want to do this from withing a process.

Really, I'd love to use crates.io crate with the following API:

hardmode::limit_cpu_frac(0.3)
matklad (Jun 12 2019 at 17:47, on Zulip):

Is anyone interested in building ^^ :)

Laurențiu Nicola (Jun 12 2019 at 17:47, on Zulip):

as a debugging aid, that cpulimit thing seems nice

Laurențiu Nicola (Jun 12 2019 at 17:47, on Zulip):

I mean it's awful, but.. :D

Nbiba Bedis (Jun 12 2019 at 17:49, on Zulip):

But the api looks really cool its tempting xD

Nbiba Bedis (Jun 12 2019 at 17:50, on Zulip):

for the Irust crate

Nbiba Bedis (Jun 12 2019 at 17:50, on Zulip):

A rust repl

Nbiba Bedis (Jun 12 2019 at 17:50, on Zulip):

for the Irust crate

marcogroppo (Jun 12 2019 at 18:30, on Zulip):

you can use cgroups via Docker (in this case with --cpus=XX). systemd-run should work too I think

Laurențiu Nicola (Jun 12 2019 at 18:50, on Zulip):

I think you can also create a cgroup manually (you need to be root), then assign RA to it while it's running

Jordan Miner (Jun 13 2019 at 17:09, on Zulip):

I posted a couple of traces on the "slow on enter" issue. The computer I was using is a quad core (8 hyperthread) 2.4GHz laptop with 28GB of RAM. Rust, the standard library, VS Code, and rust-analyzer are all on an SSD, but the project is on a hard drive. I just set up Event Tracing for Windows on this machine, and managed to record a trace when enter took a couple seconds to appear. It looks like nothing else is using the CPU during the time, just rust-analyzer using 100% of a single core.

matklad (Jun 13 2019 at 17:10, on Zulip):

Hm, interesting! That's are more powerful setup than mine, except for hard-drive part

Jordan Miner (Jun 13 2019 at 17:15, on Zulip):

If I'm using Windows Performance Analyzer right, it looks like a lot of time is spent in starting threads? Have you tried it on Windows? Maybe the panic implementation is different on Windows or Windows is a lot slower at creating threads?
slow-on-enter1.png

Jordan Miner (Jun 13 2019 at 17:16, on Zulip):

The blue vertical line in the graph is the keyboard enter event.

matklad (Jun 13 2019 at 17:19, on Zulip):

hm, fascinating!

matklad (Jun 13 2019 at 17:19, on Zulip):

let me reboot into widndows and check....

Laurențiu Nicola (Jun 13 2019 at 17:30, on Zulip):

isn't it spending time in diagnostics?

Laurențiu Nicola (Jun 13 2019 at 17:31, on Zulip):

also collecting backtraces for failure

Laurențiu Nicola (Jun 13 2019 at 17:32, on Zulip):

do you see any panics in the log window? sometimes RA seems to get stuck for a while throwing an awful lot of panics or errors

Jordan Miner (Jun 13 2019 at 17:36, on Zulip):

I see one panic in the log window, and it doesn't show any symbols in the stack trace.

Wesley Wiser (Jun 13 2019 at 17:37, on Zulip):

Windows is a lot slower at creating thread?

Windows is much slower at creating threads and panics unwinds are also more expensive due to SEH.

Laurențiu Nicola (Jun 13 2019 at 17:37, on Zulip):

why do you say it's spending a lot of time creating threads?

Jordan Miner (Jun 13 2019 at 17:47, on Zulip):

Yeah, I was wrong about that. I think it is spending a decent amount of time collecting backtraces, but I'm trying ti figure out how much.

matklad (Jun 13 2019 at 17:51, on Zulip):

@Jordan Miner you are my hero! :heart:

matklad (Jun 13 2019 at 17:51, on Zulip):

I've just tried this on windows, and yeah, that's backtraces we collect during cancellation

Laurențiu Nicola (Jun 13 2019 at 18:09, on Zulip):

wait, isn't cancellation using panics? those look like backtraces from failure

Laurențiu Nicola (Jun 13 2019 at 18:20, on Zulip):

And I think it's unlikely for that to have a real impact on interactivity

matklad (Jun 13 2019 at 18:21, on Zulip):

@Laurențiu Nicola you are also correct I think! We convert cancellation to failure::Error and I thing that's actually the point where we collect the backtrace, not the original resue_unwind

Last update: Nov 12 2019 at 16:20UTC