Hacker News Reader

Comment by swsieber | Hacker News Reader

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)

View on HN

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.

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

> Building it takes almost 40 seconds

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....

> 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?

Reply on news.ycombinator.com