Hacker News Reader

Comment by NextHendrix | Hacker News Reader

Will be interesting to see how much compile times suffer once rust starts being used more heavily in the kernel.

In my gentoo days I remember the compile time for firefox suddenly going up from 20 minutes to several hours which left a sour taste in my mouth with regards to rust.

Has there been much improvement in compile times in the past ~2 years?

View on HN

Roughly dropped by about 30% or more? Here's a dashboard that tracks times of certain benchmark tasks by compiler version: https://perf.rust-lang.org/dashboard.html

Additionally, I would expect that the kernel would mostly avoid things that drive up compile time - generics and macros.

And as someone else mentioned, things should be able to be compiled in parallel.

Also, some crates for firefox are absurdly huge in terms of compile times - they are definitely outliers (IIUC). (Edit: I was thinking of this issue in Servo, so not definitely firefox releated: https://github.com/servo/servo/issues/1799)

In particular proc macros are slow; regular macros less so.

And specifically proc-macros that parse rust-like syntax. It's the `syn` library that's slow. Proc macros that have a custom parser tend to be quite fast.

Interesting, I always assumed that syn was fast enough to not be a bottleneck. Do you have some related benchmarks, eg comparing it to the rustc and rust-analyzer parsers?

I don't, but I've definitely seen examples of non-syn proc macros that were super-fast.

This is more nuanced, as there are three separate components:

  * time to compile the syn itself
  * time to run syn on the inputs
  * time to compile whatever syn generated

I didn’t do a super thorough studies of things, but my impression is that 2, performance of syn itself, is rarely an issue. Most of the time it is 1) (and the associated problem of decreased build parallelism because half of the crates wait for syn to compile) and 3).

To get a feeling how costly a simple proc macro is, run this benchmark: https://github.com/matklad/xshell/blob/4e5090e9f79baeed1037b....

Yes, servo is an outlier. But it also apparently isn’t that bad:

> Building it takes almost 40 seconds

> Additionally, I would expect that the kernel would mostly avoid things that drive up compile time - generics and macros

There's a lot of unavoidable generic types like Option, Result, RefCell etc. Do these make up any significant part of the issue with compile times?

That page averages all the builds across different code bases. It doesn’t specify which version/tag of which code base, nor does it talk about the hardware.

https://arewefastyet.pages.dev/ - This page tracks compile times across some common crates over all supported compiler versions, with different hardware (2, 4, 8, 16 cores). This used to be https://arewefastyet.rs but the domain expired.

The tldr - speed ups of between 25-30% in these crates over the last 3 years.

Thanks for the interesting link, looks like on the whole build times have been coming down.

One interesting observation is that helloworld now takes about 4 times longer[0] (though only to 0.8 seconds). What could have caused this?

[0] https://i.imgur.com/O3viDc8.png

I’m not really sure. But since it’s stayed under a second I guess it’s not a huge deal.

Also, it’s possible that the last few releases might have sped it up a bit. That page only tracks till 1.52. I believe the latest release is 1.57.

If you do setup that in general saves time, small things sometimes won't benefit.

I think that jump was due to lto (link time optimsation) getting activated by default for Firefox on Gentoo around that time. It looked very strange at first, because the build log just pauses while the lto passes hog a lot of cpu and memory for 20min or so. Rust has been in Firefox for about 5 years now, I think.

>Has there been much improvement in compile times in the past ~2 years?

Yes. Source: https://nnethercote.github.io/2021/11/12/the-rust-compiler-h...

In my experience, compile times are more a function of project structure than anything else. The compilation unit is a crate, so keep your crates nice and small, and you'll be fine.

Insofar that it is a bunch of driver "leaves" for the forseable future, it should more embarrassing parallel.

I think rust will also have an effect on C drivers. People will rewrite their code to match safety levels. Even without rust based driver on your system you might benefit without compilation time penalty.

TLDR, yes https://blog.mozilla.org/nnethercote/2020/09/08/how-to-speed...

There has been many improvements, but it's still slow compared to ie. Go.

Security > Kernel compile time

Reply on news.ycombinator.com