from Hacker News

I Improved My Rust Compile Times

by excsn on 3/20/24, 4:14 AM with 107 comments

  • by dan_can_code on 3/20/24, 6:30 AM

    As a front-end developer dabbling with rust, the compiler being slow is not a problem for me. Whilst I appreciate the benchmark, it's not likely I'll have 72GB of ram laying around to speed up the process.

    Yes, hot module reloading is nice and quick. But it reloads with errors included.

    The primary benefit of the rust compiler, at least from my point of view, is telling me what's wrong, where. It's a worthwhile sacrifice for a few seconds of my time, when at the end of addressing all of the obvious errors, I have something that works. I find this miles better than HMR.

  • by nextaccountic on 3/20/24, 5:21 AM

    > Note: Discord User @PaulH(and a couple others) let me know about this bug that prevents the server build from using the dependencies built for the previous compilation of the server/webassembly frontend build due to changes in the RUSTFLAGS. You can fix this by having cargo-leptos > 0.2.1 and adding this to you Cargo.toml under your Leptos settings block. I did not test with this enabled.

    > [package.metadata.leptos]

    > separate-front-target-dir = true

    This option is deprecated since cargo-leptos 0.2.3 (now it's enabled unconditionally), it's going to be removed in 0.3

    https://github.com/leptos-rs/cargo-leptos/pull/216

    https://github.com/leptos-rs/cargo-leptos/issues/217

    https://github.com/leptos-rs/cargo-leptos/commit/b0c19a87cff...

  • by klabb3 on 3/20/24, 9:05 AM

    Is it an unpopular opinion to say 75% of “a lot” is still “a lot”, plus now you have to keep track of the knobs and constantly monitor for and be conscious about not wrecking build times as you’re maintaining and developing.

    I’ve found in 10+ years of software development that speed of iteration cycle is highly correlated with productivity. Compile times is not the only input into this cycle time, but it’s a big one, and importantly, it’s within the control of the language tooling itself to solve. The human idle attention time of 1-2 seconds should be the gold standard to strive for, even if not always achievable.

    There seems to be quite a bit of cope around Rust build times in the community, which was natural a few years ago (a lot of people used to “blame” llvm, but it doesn’t seem to be as big of a culprit) but things are different now, no? Given the maturity, growing ecosystem and corporate investment, I would expect incremental build speedup to be prioritized, and steadily improving. But clearly it isn’t moving very fast in that direction. So why not?

  • by rui314 on 3/20/24, 6:15 AM

    The sold linker is no longer commercial software; it's been relicensed under the MIT license.

  • by denysvitali on 3/20/24, 5:14 AM

    Their benchmarks are based on a machine with 72GB of RAM and another with 128GB of RAM - not that it does matter, but I'm really curious if they're outliers or if I should bump my computer specs. That's a lot of Electron web apps running in parallel!

  • by KingOfCoders on 3/20/24, 8:16 AM

    From my experience, faster SSD have a suprising strong effect for some (simple) languages (probably not Rust), like Go [0]

    [0] https://www.octobench.com/

  • by dgellow on 3/20/24, 9:40 AM

    I’m not sure I understand why editing an html template requires to recompile the rust project. I implemented a static site generator in rust for my own projects, html templates are simple liquid template files, it’s instant to recompile them. Same for stylesheets. Is the author generating the html from rust directly? If yes that sounds like a painful strategy

  • by rbalint on 3/20/24, 2:11 PM

    75% is really good even if it requires changing the toolchain. Have you tried https://github.com/firebuild/firebuild ? It is a caching accelerator and it can cache the linking and the buildscripts, too in Rust builds. It can make your builds more than 90% faster, especially with low cores counts. https://balintreczey.hu/blog/improve-build-time-of-rust-java... The Mac port is experimental, though.

  • by SushiHippie on 3/20/24, 7:01 AM

    Looking at some benchmarks online and the 7900x always beat the 5950x even though the 5950x has more cores.

    But in this article the 7900x performed worse than the 5950x, is it because of the core count, or are there some other factors?

  • by eikenberry on 3/20/24, 4:59 AM

  • by daghamm on 3/20/24, 7:05 AM

    First time I hear about mold.

    The performance looks good, but are there any plans for any other improvements such as LTO?

  • by winrid on 3/20/24, 6:47 AM

    The coolest thing about this to me IMO is the comparison between the two CPUs.

    Is there a project that publishes benchmarks compiling projects across different CPUs? I know passmark is kinda the go-to but this would be cool.

    Someday I'll feel the need to upgrade from a 2700x...

  • by richrichie on 3/20/24, 9:49 AM

    The older i get the more i am convinced that there-ain’t-no-free-lunch applies widely, beyond financial markets.

    Software development: the art of redistributing aggregate lifecycle pain; who bears what, when and how much.

  • by tempaccount420 on 3/20/24, 5:12 AM

    Very cool, still kind of disappointing the author was only able to get incremental compilation down to 4.5s, no matter the baseline. Hopefully Cranelift lands in stable at some point.

  • by beeb on 3/20/24, 6:56 AM

    Super interesting! I would have loved to see included in the potential solutions the use of sccache too

  • by rob74 on 3/20/24, 7:53 AM

    I really wish people wouldn't use AI-generated images for blog posts, it's so distracting! I clicked the link wanting to read the article, but instead spent several minutes looking at the image to find errors: what's shown on the screen (apparently it's "Jot Commeditin") looks like something between a hex dump, git blame, and occult incantations written in a long-forgotten alphabet. Probably you need a keyboard like the one on the desk (with keys arranged in a fractal pattern) to write something like that. And a mouse with a cable going nowhere...