I'd vote for filesystem space utilization to be worked on before performance.
What’s stopping cargo from storing libraries in one global directory(via hash or whatever), to be re-used whenever needed?
You can: https://github.com/mozilla/sccache
Rust compiler performance
21–30 of 264 posts
Re: Rust compiler performance
#22Having worked on large scale C++ code-bases and thus used to long compilation times, it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust.
It is a quantifiable negative to which you can always point. Of course it will be used for justifications.
Re: Rust compiler performance
#23Having worked on large scale C++ code-bases and thus used to long compilation times, it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust.
There's a lot of things you can do in C++ to reduce compilation time if you care about it, that aren't possible with Rust.
Re: Rust compiler performance
#24Re: Rust compiler performance
#25I'd vote for filesystem space utilization to be worked on before performance.
Performance has been worked on since Rust 1.0 or so, for all this time, there has been lots of work on compiler performance. There's no "before performance" :)
There are multiple avenues to improve both first and incremental compiles. They "just" require large architectural changes that may yield marginal improvements, so it's hard to get those projects off the ground. But after the last project all-hands I do expect at least one of these to be pursued, of not more.
There are cases where cargo recompiles crates "unnecessarily", cargo+rustc could invert the compilation pyramid to start at the root and then only compile reachable items (similar effect to LTO, but can produce a binary if an item with a compile error isn't evaluated, improving clean compiles), having better communication with linkers and having access to incremental linking would be a boon for incremental compiles, etc.
Re: Rust compiler performance
#26The original title is:
Why doesn't Rust care more about compiler performance?
Re: Rust compiler performance
#27Compiler performance must be considered up front in language design. It is nearly impossible to fix once the language reaches a certain size without it being a priority. I recently saw here the observation that one can often get a 2x performance improvement through optimization, but 10x requires redesigning the architecture.
Rust can likely never be rearchitected without causing a disastrous schism in the community, so it seems probable that compilation will always be slow.
Re: Rust compiler performance
#28I'm a big fan of Rust but there are definitely warts that are going to be difficult to cure [1]. This is 5 years old now but I believe it's still largely relevant.
It is a weird hill to die on for C/C++ devs though, given header files and templates creating massive compile-time issues that really can't be solved.
Google is known for having infrastructure for compiling large projects. They use Blaze (open-sourced at Bazel) to define hermetic builds then use large systems to cache object graphs (for compilation units) and caching compiled objects because Google uses some significant monoliths that would take a significant amount of time to compile from scratch.
I wonder what this kind of infrastructure can do for a large Rust project.
[1]:https://www.pingcap.com/blog/rust-compilation-model-calamity...
Re: Rust compiler performance
#29Having worked on large scale C++ code-bases and thus used to long compilation times, it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust.
>> it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust
I believe people will exaggerate their current issue so it sounds like the only thing that matters to them. On another project I've had people say "This is the only thing that keeps me using commercial alternatives" or the only thing holding back wider adoption, or the only thing needed for blah blah blah. Meanwhile I've got my own list of high priority things needed to bring it to what I'd consider a basic level of completeness.
When it comes to performance it will never be good enough for everyone. There is always a bigger project to consume whatever resources are available. There are always people who insist on doing things in odd ways (maybe valid, but very atypical). These requests to improve are often indistinguishable from the regular ones.
Re: Rust compiler performance
#30Maybe these features already exist, but I'd like a way to: 1) Type check without necessarily building the whole thing. 2) Run a unit test, only building the dependencies of that test. Do these exist or are they remotely feasible?