So... grumpy old man response here:<p>These are all tiny, targetted microoptimizations worth a percent or three of benefit in specific tests. They're worth doing (or at least evaluating) in any mature product and I have no complaint.<p>Nonetheless rustc remains <i>really</i> slow relative to other similar technologies, including C++ compilers. Is there any consensus as to why?<p>I mean, with C++, the answer is something to the effect of "template expansion happens syntactically and generally has to be expressed in headers, leading to many megabytes of code that has to be compiled repeatedly with every translation unit". And that isn't really amenable to microoptimization. We all agree that it sucks, and probably can't be fixed with the language as it's specified, and chalk it up to a design flaw.<p>What's the equivalent quip with rustc? I mean... is it going to get faster (in a real sense, not micro), or is it not? Is this fixable or not, and if not why?
If you're interested in the current "grand plans" for performance, check out this issue: <a href="https://github.com/rust-lang/rust/issues/48547" rel="nofollow">https://github.com/rust-lang/rust/issues/48547</a><p>The query parallelization work has been coming along. Also it was recently discovered that building LLVM with a recent clang and doing cross-language LTO speeds up builds by ~25%.
A recent good experience with rust: wanted to learn a little about machine learning. Found a crate called rusty-machine, copied some examples from the docs, and built them.<p>No problems, compiling all of the dependencies was fast, examples worked, and in literally about 2 minutes I had a neural net and was hacking on it.<p>This is without touching rust in months.
Total noob question here, but how does the hardware you're using affect compilation speed? What's the baseline hardware being used in this benchmark he runs? There's no way to recreate the benchmark environment unless we know this.<p>When someone like ajross says rustc is <i>really</i> slow, how slow are we talking?