Live data from Hacker News

Thoughts on Rust bloat

raphlinus.github.io

311–313 of 313 posts

Re: Thoughts on Rust bloat

#311

Earlier quoted context omitted.

Any time you have an error/exception/abort path, you always never want to inline it (LLVM prob has attributes to prevent that, but I'm not sure if they are used by rust). Also, LLVM does get a little too aggressive with things like unrolling so I wouldn't be surprised if it inlined too aggressively too.

They are used by Rust.

How does it tell an unimportant error path from a needs to be optimized common case (this is where exceptions would be great).

Re: Thoughts on Rust bloat

#312
To respond to one particular point from the post:

> Once you accept bloat, it’s very hard to claw it back. If your project has multi-minute compiles, people won’t even notice a 10s regression in compile time. Then these pile up, and it gets harder and harder to motivate the work to reduce bloat, because each second gained in compile time becomes such a small fraction of the total.

This particular problem can be addressed head-on, I think. It would seem feasible to have the compiler to distinguish between the target application (library) and the dependencies. Then it could report the compile times as separate values. This could be built into CI/CD tools as a way to catch application level compile time changes.

Of course, this approach wouldn’t tell the entire story, but it would likely serve as a canary in the coal mine at least.

Re: Thoughts on Rust bloat

#313
post #41

Seems like a lot of this comes from rust defaulting to allowing several different versions of a library to be linked in ... there’s def some other pieces. But that seems like a biggie

Do you know how to not do this "default"? I would love to try it.

i would love to, too!

:)

Post reply on HN