Slow and memory-intensive compilation with debug symbols

[speshuric]

Here is code:

// NOTE: this fn is executed 2^N times
fn f00(i: i64) -> i64 {i + i}

// we need to go deeper!
fn f01(i: i64) -> i64 {f00(i) + f00(i)}
fn f02(i: i64) -> i64 {f01(i) + f01(i)}
fn f03(i: i64) -> i64 {f02(i) + f02(i)}
fn f04(i: i64) -> i64 {f03(i) + f03(i)}
fn f05(i: i64) -> i64 {f04(i) + f04(i)}
fn f06(i: i64) -> i64 {f05(i) + f05(i)}
fn f07(i: i64) -> i64 {f06(i) + f06(i)}
fn f08(i: i64) -> i64 {f07(i) + f07(i)}
fn f09(i: i64) -> i64 {f08(i) + f08(i)}
fn f10(i: i64) -> i64 {f09(i) + f09(i)}

// deeper
fn f11(i: i64) -> i64 {f10(i) + f10(i)}
fn f12(i: i64) -> i64 {f11(i) + f11(i)}
fn f13(i: i64) -> i64 {f12(i) + f12(i)}
fn f14(i: i64) -> i64 {f13(i) + f13(i)}
fn f15(i: i64) -> i64 {f14(i) + f14(i)}
fn f16(i: i64) -> i64 {f15(i) + f15(i)}
fn f17(i: i64) -> i64 {f16(i) + f16(i)}
fn f18(i: i64) -> i64 {f17(i) + f17(i)}
fn f19(i: i64) -> i64 {f18(i) + f18(i)}
fn f20(i: i64) -> i64 {f19(i) + f19(i)}

// ... and deeper
/*fn f21(i: i64) -> i64 {f20(i) + f20(i)}
fn f22(i: i64) -> i64 {f21(i) + f21(i)}
fn f23(i: i64) -> i64 {f22(i) + f22(i)}
fn f24(i: i64) -> i64 {f23(i) + f23(i)}
fn f25(i: i64) -> i64 {f24(i) + f24(i)}
fn f26(i: i64) -> i64 {f25(i) + f25(i)}
fn f27(i: i64) -> i64 {f26(i) + f26(i)}
fn f28(i: i64) -> i64 {f27(i) + f27(i)}
fn f29(i: i64) -> i64 {f28(i) + f28(i)}
fn f30(i: i64) -> i64 {f29(i) + f29(i)}

// ... and deeper
fn f31(i: i64) -> i64 {f30(i) + f30(i)}
fn f32(i: i64) -> i64 {f31(i) + f31(i)}
fn f33(i: i64) -> i64 {f32(i) + f32(i)}
fn f34(i: i64) -> i64 {f33(i) + f33(i)}
fn f35(i: i64) -> i64 {f34(i) + f34(i)}
fn f36(i: i64) -> i64 {f35(i) + f35(i)}
fn f37(i: i64) -> i64 {f36(i) + f36(i)}
fn f38(i: i64) -> i64 {f37(i) + f37(i)}
fn f39(i: i64) -> i64 {f38(i) + f38(i)}
fn f40(i: i64) -> i64 {f39(i) + f39(i)}

// ... and deeper
fn f41(i: i64) -> i64 {f40(i) + f40(i)}
fn f42(i: i64) -> i64 {f41(i) + f41(i)}
fn f43(i: i64) -> i64 {f42(i) + f42(i)}
fn f44(i: i64) -> i64 {f43(i) + f43(i)}
fn f45(i: i64) -> i64 {f44(i) + f44(i)}
fn f46(i: i64) -> i64 {f45(i) + f45(i)}
fn f47(i: i64) -> i64 {f46(i) + f46(i)}
fn f48(i: i64) -> i64 {f47(i) + f47(i)}
fn f49(i: i64) -> i64 {f48(i) + f48(i)}
fn f50(i: i64) -> i64 {f49(i) + f49(i)}*/

fn main() {
    let mut i:i64 = 0;
    i = f20(i); // point here the last fNN
    println!("{i}");
}

Change commented area and see how the code is compiled with different opt-level and debuginfo:

rustc -C opt-level=...l -C debuginfo=... ./c20.rs

Expected: code compilation time does not exceed something about 10 s and memory usage does not exceed 1 GiB

Actual:

debuginfo:	0	0	0	0	1	1	1	1	2	2	2	2
opt-level:	0	1	2	3	0	1	2	3	0	1	2	3
c10.rs	0.00	0.09	0.09	0.09	0.09	0.09	0.09	0.10	0.09	0.09	0.22	0.22
c15.rs	0.09	0.09	0.10	0.10	0.09	0.09	0.15	0.14	0.09	0.09	127.23	124.11
c20.rs	0.09	0.09	0.37	0.40	0.09	0.09	1.65	1.63	0.09	0.09	>10000	>10000
c30.rs	0.09	0.10	5.88	5.80	0.09	0.09	31.11	31.77	0.09	0.09	--	--
c40.rs	0.09	0.09	5.79	5.58	0.09	0.09	30.55	31.43	0.09	0.09	--	--
c50.rs	0.09	0.09	5.67	6.14	0.09	0.09	30.83	31.30	0.09	0.09	--	--

And memory usage is high with debuginfo=2.
cNN.rs is file with fNN the last function uncommented and invoked.

Meta

rustc --version --verbose:

rustc 1.88.0-nightly (b8c54d635 2025-04-20)
binary: rustc
commit-hash: b8c54d6358926028ac2fab1ec2b8665c70edb1c0
commit-date: 2025-04-20
host: x86_64-unknown-linux-gnu
release: 1.88.0-nightly
LLVM version: 20.1.2

[bjorn3]

All the time is spent inside LLVM. I guess LLVM is quadratic in the debuginfo depth.

[speshuric]

I guess LLVM is quadratic in the debuginfo depth.

Umm... My recent LLVM issue shows exponential slowdown.

[bjorn3]

Right, mixed up the two terms.

[workingjubilee]

@speshuric Did you reach this in a non-artificial reproducer?

[speshuric]

@workingjubilee I found this case when I was investigating a significant but not so critical slowdown in compiling auto-generated files (something like fuzzing). So I made this "distilled" repro: excessive inline + debug info. I don't think this is high priority issue.

[workingjubilee]

Good to know!

We do care about generated code when it's generated in the "like-a-proc-macro" sense, but obviously fuzzer code is a bit different.