There are many potential improvements we could make for build times. In the course of evaluating possibilities, we'd like to know how much impact debug information has on build time.
Could people provide feedback on the build time differences in their projects between the default dev profile configuration and with the following added?
[profile.dev]
debug = "line-tables-only"
Ideally, we'd love to get the performance delta for a couple of cases:
A clean cargo build after cargo clean.
After doing cargo build, using touch on your lib.rs or main.rs, and then doing cargo build again.
I tried my Project Euler solutions with 340 binaries (for each I've solved) and 70 dependencies. This is potentially heavy as it involves lots of linking with debuginfo, but they're also pretty small.
With the default profile, cargo build took 23.34s; after touching lib.rs, it took 11.17s.
With "line-tables-only", cargo build took 20.84s; after touching lib.rs, it took 10.00s.
I mean if commenters here posted those tidbits (os, linker, split debuginfo) it could provide more context in case there are discrepancies in their numbers.
I recently ran an informal survey about whether people regularly use a debugger. Of the 89 responses, 18% say they sometimes or always use a debugger while 82% say they rarely or never use a debugger. This seems consistent with what I've observed from talking to rustaceans in person.
I'm definitely supportive of any change to reduce the debug info for a default build.
I think that line number information in backtraces is less important now that it used to be and the reason is #[track_caller]. Generally the line that I care about when I get a backtrace is the line that called unwrap, expect, panic etc and these days that line is reported whether or not you have line debug info. So personally, I set debug=0, but I can understand that's likely a step too far for the default - just changing to line-tables by default would be great.
Does line-tables-only debug information still provide enough detail that GDB's bt command (or equivalent in your favorite debugger) can print the values of function arguments? I would really miss that if it went away by default.
I think this will only be a net win when tests are taking a non-trivial amount of time already. If you only got a couple of tests or are only doing say cargo run for a web server that starts up instantly, it would likely only slow down things.
I wonder if it would be feasible to provide automatic tuning. Imagine if cargo test would:
Measure both the compile time and the test run time, and remember this over multiple sessions.
If historical run time is high relative to compile time, run an experiment (with a note to the user that this is happening): switch to opt-level = 1.
Based on the results of the experiment, decide whether to keep it — and maybe suggest to the user to configure [profile.dev].
The biggest problem with this would be that it triggers a rebuild of all dependencies, which is a potentially large interruption. This would be less of a problem if the default dev profile always compiled dependencies with more optimization, so only the workspace needs to be rebuilt.
Alternatively, you could ask Cargo to run the experiment explicitly and choose the best settings, as a single command, but this has the problem that it doesn't know what kind of edits you're going to be making and thus it can't reproduce the right incremental build cost (unless it saves copies of your edited source files)
Could cargo automatically make the distinction between outside-workspace dependencies (since those are unlikely to need recompiles) and apply a higher opt-level to those so that people don't have to set it via [profile.dev.package."*"] manually?
