TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Reducing Rust Incremental Compilation Times on macOS

186 pointsby yannikyeoabout 4 years ago

7 comments

nindalfabout 4 years ago
Compile times in rustc have been steadily improving with time, as shown here - <a href="https:&#x2F;&#x2F;arewefastyet.rs" rel="nofollow">https:&#x2F;&#x2F;arewefastyet.rs</a>.<p>Every release doesn&#x27;t make every workload faster, but over a long time horizon, the effect is clear. Rust 1.34 was released in April 2019 and since then many crates have become 33-50% faster to compile, depending on the hardware and the compiler mode (clean&#x2F;incremental, check&#x2F;debug&#x2F;release).<p>Interestingly, the speedup mentioned in OP won&#x27;t show up in these charts because that&#x27;s a change on macOS and these benchmarks were recorded on Linux.<p>What is expected to be a gamechanger is the release of cranelift in 2021 or 2022. It&#x27;s an alternate debug backend that promises much faster debug builds.
Decabytesabout 4 years ago
Are long compile times just a product of Rust’ design? Or is there an issue with the compiler. Based on my experience with rust I would say it’s the former. It’s doing so many more checks for you then other compilers to prevent lots of problems that it’s bound to be slow.<p>I appreciate that they continue to speed up compilation&#x2F;add flags. If the compiler gets slower every release it will eventually become unusable. I think the long compilation times will continue to get worse in the future as the rust compiler gets better at checking for errors, and I’m not sure what can really be done about that.<p>One thing that irks me is that they throw around the phrase zero cost abstraction a lot. And I just don’t buy it. Sure I get it, lots of things can be monomorphized so we don’t pay a runtime cost, but there is still a large compilation hit to do that, and it’s not zero cost to the programmer. One need only to look at Chandler Carruth’s cppcon talk “there are no zero cost abstractions” to understand that.
评论 #26852193 未加载
评论 #26852029 未加载
评论 #26854574 未加载
评论 #26855837 未加载
评论 #26852496 未加载
评论 #26852331 未加载
评论 #26852197 未加载
评论 #26857122 未加载
est31about 4 years ago
You can also turn off debuginfo completely. Personally, someone who does printf debugging, I mainly need it to debug segfaults, which are really rare in Rust. Sometimes the call stack of a panic is useful as well, but if I need debuginfo I can just re-enable it.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;est31&#x2F;cargo-udeps&#x2F;commit&#x2F;e550d93c7a6d756e639ecd7f117ea9f9328d3b38" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;est31&#x2F;cargo-udeps&#x2F;commit&#x2F;e550d93c7a6d756e...</a>
评论 #26852898 未加载
imronabout 4 years ago
&gt; Dev rebuilds lasting 14 seconds was getting me a bit worried<p>I wish my dev builds only took 14 seconds...
评论 #26852811 未加载
pjmlpabout 4 years ago
On the other hand I just gave up expecting sscache to build on my travel netbook, &gt; 400 dependencies, really?<p><i>apt-get install rustlibXYZ-dev</i> can&#x27;t come soon enough.
评论 #26851954 未加载
xenadu02about 4 years ago
I&#x27;m not sure why Rust doesn&#x27;t emit the debug info in the Mach-O. The executable can still be moved to another system and debugged but it doesn&#x27;t require a second pass to generate a separate dSYM.
评论 #26851811 未加载
评论 #26850941 未加载
orfabout 4 years ago
Why is this not the default? What’s the downside?
评论 #26852030 未加载