I use VS Code for debugging, and noticed that updating variables takes more than half a minute. It usually times out and then runs ok on the second attempt.
I wonder what can be the reason?
The sub-crate (inside a workspace) became heavy when bincode and zerocopy derive macros met together in some structs. Saving the file is slow, although it doesn't time out.
Is this because of rust analyzer slowdown, or is there any other reason?
update: I removed the 3-4 zerocopy derives. Editing and saving is a bit better. But running the debugger suffers the same way. Actually, after launching, things are fast, it comes to a breakpoint almost instantly. It's just the variables panel that take ages to load the data.
update2: what could be a cause is that I ran a profiler, and could have changed things. 1) /proc/sys/kernel/perf_event_paranoid was changed. I set it back to value 4 that was originally - no effect. 2) a setting in cargo.toml of the sub-crate: [profile.release] debug=2. This I think had no effect. Removing it hadn't either. 3) just a bad crate? I had added indicatif, but removing it changed nothing.
update3: I walked through code and removed the zerocopy derive macros where they were together with bincode. It made rust analyzer process everything much quicker on save. But the variables panel is still refreshes very slowly (it times out the first time).
I have no other var/watch expression in debugger, and just 1 breakpoint.
update4: I rebooted, and now it's broken completely: the debugger doesn't start at all, showing me this:
/home/culebron/.vscode/extensions/vadimcn.vscode-lldb-1.11.5/adapter/codelldb terminal-agent --connect=43261
Error: No such file or directory (os error 2)```
rust-analyzer runs cargo check on save by default.
try run cargo check or cargo build with the --timings flag, then you'll find a report under target/cargo-timings/ directory, you should at least find out which crate is the slowest to compile.
did you launch the debugger using a launch.json profile, or via the rust-analyzer code lens above main()?
this error message seems indicate the debug target is not found, did you run cargo clean?
I launch via launch.json, and with a fresh look, I noticed that in args, there are files from /tmp/, which were deleted, and the app correctly wrote "file not found" and exited. I thought it was code-lldb bug So, VS Code isn't broken.
Regarding --timings, I tested, it runs in 0.04s on the same binary. When I add a line to the code, it also gets saved quickly, no hickups. (maybe because i removed that bunch of zerocopy derives).
But the variables in the side panel still take ~18s to update. I see in € top or € htop that codelldb uses 99% of 1 CPU core all this time.
A quick test on an empty crate shows that codelldb updates everything fast. So, it's something in my crate that makes it work so slowly.
Ok, I found the reason. Indeed, the combination of Zerocopy & Bincode_next derives caused this heavy slowdown. Derives from just one of these crates caused no such issue.
I'm guessing it's probably some quirky debug symbol corner case, e.g. maybe the combination of the derived code triggered some debug infor parsing/decoding bug in codelldb.
when the program is paused, e.g. hitting a break point or single stepping, the debugger needs to a lot to update the ui do display the values of local variables, watched expressions, etc.
in simplified words, it needs to map the program counter into file name and line number and function names, and then it must figure out which variables are active in the current scope/frame and what's their memory location, then it needs to read the contents from the memory, and it also needs to decode the type information of the variables to format the value for display. all these relies on the debug info. if it had hard time decoding the debug info, you see slow ui updates or timeouts.
I think it deserves a bug report to codellvm, at least worth some investigation, especially given that neither zerocopy nor bincode_next would trigger the problem alone, but the combination of the two will, this seems very peculiar.
So, VS Code isn't broken.