Feedback request: Performance improvements from reducing debug info

1

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.
1 Like
2

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.
3 Likes
3

For one of my projects, a clean default dev profile gives:

Finished `dev` profile [unoptimized + debuginfo] target(s) in 6m 12s

A clean debug = "line-tables-only" build:

Finished `dev` profile [unoptimized + debuginfo] target(s) in 5m 02s

With the default profile, after touching main.rs/lib.rs:

Finished `dev` profile [unoptimized + debuginfo] target(s) in 16.59s

With debug = "line-tables-only", after touching main.rs/lib.rs:

Finished `dev` profile [unoptimized + debuginfo] target(s) in 14.21s
4
  • default profile:
    • cargo clean then cargo build: 7.36s
    • touch main.rs then cargo build: 1.09s
  • with debug = "line-tables-only":
    • cargo clean then cargo build: 6.62s
    • touch main.rs then cargo build: 0.86s
5

It would perhaps also worth including times for split-debuginfo which could presumably impact link times?

1 Like
6

There are also other factors to consider such as the linker used and the OS

1 Like
7

Better linkers can make this better, but it still takes time to do the work.

8

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.

9

Testing on Fedora 40 x86_64.

Default dev profile:

Post cargo clean: cargo build 385.75s user 34.70s system 599% cpu 1:10.08 total

After touching main.rs: cargo build 3.91s user 1.23s system 99% cpu 5.151 total

With debug = "line-tables-only"

Post cargo clean: cargo build 353.69s user 34.42s system 619% cpu 1:02.62 total

After touching main.rs: cargo build 2.86s user 1.02s system 99% cpu 3.881 total

1 Like
10

ubuntu + mold

Less chonky executable, default profile clean build followed by touch on lib.rs and one more build

    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1m 57s
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 7.16s

Same, but with line-tables-only

    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1m 46s
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 4.80s

More chonky executable, all 4 cases

    Finished `dev` profile [unoptimized + debuginfo] target(s) in 2m 22s
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 4.68s

    Finished `dev` profile [unoptimized + debuginfo] target(s) in 2m 03s
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.29s
4 Likes
11

Ubuntu-based with Wild as the linker

Smallish build (10MiB binary):

default cold: 22.49s
line-tables cold: 20.78s
debug=0 cold: 19.66s

default warm: 0.24s
line-tables warm: 0.20s
debug=0 warm: 0.18s

Larger build (several binaries around 450MiB each):

default cold: 4m 51s
line-tables cold: 3m 46s
debug=0 cold: 3m 16s

default warm: 4.48s
line-tables warm: 2.28s
debug=0 warm: 1.63s

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.

3 Likes
12

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.

1 Like