4 ms·

> I keep reading in Rust surveys that Rustaceans just don't care that much about compile times enough to prioritize improving them. Confusing since this is, to

> I keep reading in Rust surveys that Rustaceans just don't care that much about compile times enough to prioritize improving them. Confusing since this is, to my knowledge, a top 3 issue just about every year. That said, I think Rust programmers dislike compromise (maybe to a fault). Rust is naturally a 'have your cake and eat it to' language and the community very much likes to be best-in-class, so compromises on runtime performance to improve compile time (which is one way you can go today) are often not seen as viable by a large part of the community. For what it's worth, I think I've called out compile times as probably one of my top issues with Rust, working on a fairly large and quite dependency heavy codebase. It isn't a deal breaker for me by any means, but it's a pain.

whatshisface 6y ago
>compromises on runtime performance to improve compile time (which is one way you can go today) are often not seen as viable by a large part of the community. Typically this tension would be resolved with o-level flags (O1, O2, O3...).
- steveklabnik 6y ago
  Rust has those, though most people interact with them through cargo (with --release corresponding to O3 and not passing it to O0.) Sometimes, non-release builds are too slow to meaningfully run. It is not uncommon for release builds to be extremely faster than debug builds.
  - whatshisface 6y ago
    Might we get an -O2?
    - steveklabnik 6y ago
      It exists as well, and if you want to use it, it's a short "throw the option in your cargo config and call it a day." That being said, I'm not aware of it making any meaningful difference.
- staticassertion 6y ago
  I think the tricks are more like "use dynamic dispatch instead of static dispatch". O1 vs O3 is probably a fair way to do things. Some people will do that for debug builds, to get a mix of reasonable performance (for tests) and reasonable compile times. I'm not sure how meaningful the difference is going to be between O2 and O3, it's been a long time since I'd looked into it, and back then O3 wasn't really a thing people did.

whatshisface 6y ago

>compromises on runtime performance to improve compile time (which is one way you can go today) are often not seen as viable by a large part of the community. Typically this tension would be resolved with o-level flags (O1, O2, O3...).

steveklabnik 6y ago
Rust has those, though most people interact with them through cargo (with --release corresponding to O3 and not passing it to O0.) Sometimes, non-release builds are too slow to meaningfully run. It is not uncommon for release builds to be extremely faster than debug builds.
- whatshisface 6y ago
  Might we get an -O2?
  - steveklabnik 6y ago
    It exists as well, and if you want to use it, it's a short "throw the option in your cargo config and call it a day." That being said, I'm not aware of it making any meaningful difference.
staticassertion 6y ago
I think the tricks are more like "use dynamic dispatch instead of static dispatch". O1 vs O3 is probably a fair way to do things. Some people will do that for debug builds, to get a mix of reasonable performance (for tests) and reasonable compile times. I'm not sure how meaningful the difference is going to be between O2 and O3, it's been a long time since I'd looked into it, and back then O3 wasn't really a thing people did.