Hacker News Reader

Comment by aw1621107 | Hacker News Reader

For what it's worth, according to the PR that added the annotation [0] doing so generally resulted in decreases in compile times and binary sizes on benchmarks. Furthermore, an additional experiment that avoided emitting the inline attribute on structs with >5 fields resulted in benchmark regressions compared to always emitting the attribute [1]. I'd guess this is one of those things which may help in aggregate but hurts for specific cases.

That being said, one of the Rust devs indicated in the corresponding lobste.rs discussion [2] that they're open to revisiting/rebalancing things if they get enough bug reports indicating something is up, so it might not hurt to tag onto the bug report the author will (hopefully) eventually submit.

[0]: https://github.com/rust-lang/rust/pull/117727

[1]: https://github.com/rust-lang/rust/pull/118031

[2]: https://lobste.rs/s/dldhpw/rust_s_derive_often_implies_inlin...

View on HN

A reasonable conjecture was raised on lobsters that this is because `#[inline]` makes actual codegen (LLVM IR and down from MIR) lazy, and most `Debug` impls are never used.

How much code is never used and compilation could be skipped entirely? Maybe applying a reachability pass to skip compiling unused code would be helpful.

A cross-crate dead code analysis would mean that compilation of a crate now depends on information about its dependents. This would break reuse of compiled crates and cause recompiles when the analysis changes.

Something does seem a little off about this, though. Ideally for this `Debug` case there would be an annotation that says "compile this lazily, don't inline". Maybe there doesn't even need to be a new annotation, just `#[inline] #[cold]`. Which looks pretty weird, but might work already.

`#[inline]` in Rust is weird and not similar to `inline` in C or C++. It has two effects: it duplicates the MIR for every codegen unit that needs it instead of precompiling (which is what causes the laziness, and also why it's commonly recommended to avoid `#[inline]` on generic functions as this happens anyway for them), and also adds LLVM `inlinehint`. It is possible to avoid the second but not the first if you want to stay lazy, and that can also cause code duplication (unless you set `codegen-units = 1`) and LLVM deciding to inline things even without the hint.

And `#[inline] #[cold]` doesn't work: it adds both `inlinehint` and the cold hint to LLVM. Which may cause, for example, the function to be inlined but the branch be marked cold for better machine code organization.

I've said for a while that I think that the "real" issue with compile times is that there's a ton of dead code getting compiled across the dependency tree. I personally blame Cargo features not being ergonomic enough, because on paper they're perfectly suited to solve this problem, but in practice the amount of boilerplate needed to use them for this is infeasible. I wrote a manifesto about this a while back: https://saghm.com/cargo-features-rust-compile-times/

So the thesis is that crates massively oversubscribe the features of their dependencies, and that if features were managed more carefully and maybe dependency features exposed through each crate's own exposed feature list, that would cut down on dependency bloat and compile times a lot.

My idea above is roughly equivalent to the "zero-config" strategy you mention.

It's kinda crazy that if a direct dependency doesn't use some feature from a transitive dependency and the direct dependency forgets to disable it or expose a way to disable it you're still stuck with it.

Yes, as long as by "the features of their dependencies" you mean this in the conceptual sense rather than the actual Cargo feature called "cargo features", that's my thesis, although with an additional explicit point that in the current way the system works, there's virtually no way to do this effectively. It seems like you understood that as well, but I think it's a much more bold claim for me to say that the problem is fundamentally ergonomic because the thing that does solve it in theory exists but will be used for that in practice in the current form.

Putting it another way that's even more controversial, because I do genuinely believe it and I think we need to radically change how we think about this: I don't think the Rust compiler is slow. I think that it just compiles too much code, and if we solved that, we'd find that it's fast enough in practice that most people would stop complaining about compile times.

That makes sense. If you're a library, it's just good manners to derive Debug on types that you don't have a good reason not to, but you have no way of knowing if anyone will actually use it in a given program.

Thanks, interesting!

Reply on news.ycombinator.com