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?
you can also set the nice to a larger value, but I'm not sure it's a good idea
if you throttle RA, you'll end up waiting more for it to return the results
maybe a better approach is to wait a little before processing the client requests? like that old "wait 250ms before showing completions" trick
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
Ah, got it. I thought you wanted to slow down RA to help people with slower computers, but it's for testing.
yeah, I want to slow RA to help people with fast computers :D
it even works for processes that are already running
It does this by sending SIGSTOP and SIGCONT signals to the process.
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:
Is anyone interested in building ^^ :)
as a debugging aid, that
cpulimit thing seems nice
I mean it's awful, but.. :D
But the api looks really cool its tempting xD
for the Irust crate
A rust repl
for the Irust crate
you can use cgroups via Docker (in this case with
systemd-run should work too I think
I think you can also create a cgroup manually (you need to be root), then assign RA to it while it's running
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.
Hm, interesting! That's are more powerful setup than mine, except for hard-drive part
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?
The blue vertical line in the graph is the keyboard enter event.
let me reboot into widndows and check....
isn't it spending time in diagnostics?
also collecting backtraces for
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
I see one panic in the log window, and it doesn't show any symbols in the stack trace.
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.
why do you say it's spending a lot of time creating threads?
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.
@Jordan Miner you are my hero! :heart:
I've just tried this on windows, and yeah, that's backtraces we collect during cancellation
wait, isn't cancellation using panics? those look like backtraces from
And I think it's unlikely for that to have a real impact on interactivity
@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