4 ms·

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.

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 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 https://github.com/servo/servo/issues/1799)

loeg 5y ago
In particular proc macros are slow; regular macros less so.
- nicoburns 5y ago
  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.
  - the_duke 5y ago
    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?
    - nicoburns 5y ago
      I don't, but I've definitely seen examples of non-syn proc macros that were super-fast.
    - matklad 5y ago
      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/4e5090e9f79baeed1037bc0925a6a84174566eb1/tests/it/main.rs#L441 https://github.com/matklad/xshell/blob/4e5090e9f79baeed1037b....
seoaeu 5y ago
Yes, servo is an outlier. But it also apparently isn’t that bad: > Building it takes almost 40 seconds
Asraelite 5y ago
> 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?
nindalf 5y ago
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/ 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 https://arewefastyet.rs but the domain expired. The tldr - speed ups of between 25-30% in these crates over the last 3 years.
- NextHendrix 5y ago
  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 https://i.imgur.com/O3viDc8.png
  - nindalf 5y ago
    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.
  - adgjlsfhk1 5y ago
    If you do setup that in general saves time, small things sometimes won't benefit.

loeg 5y ago

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

nicoburns 5y ago
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.
- the_duke 5y ago
  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?
  - nicoburns 5y ago
    I don't, but I've definitely seen examples of non-syn proc macros that were super-fast.
  - matklad 5y ago
    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/4e5090e9f79baeed1037bc0925a6a84174566eb1/tests/it/main.rs#L441 https://github.com/matklad/xshell/blob/4e5090e9f79baeed1037b....

seoaeu 5y ago

Yes, servo is an outlier. But it also apparently isn’t that bad: > Building it takes almost 40 seconds

Asraelite 5y ago

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

nindalf 5y ago

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/ 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 https://arewefastyet.rs but the domain expired. The tldr - speed ups of between 25-30% in these crates over the last 3 years.

NextHendrix 5y ago
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 https://i.imgur.com/O3viDc8.png
- nindalf 5y ago
  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.
- adgjlsfhk1 5y ago
  If you do setup that in general saves time, small things sometimes won't benefit.