5 ms·

Tried out the instructions from the article on a tiny Bevy project, and compared it to a "normal" build: > cargo build --release 23.93s user 22.85s system 66%

by diggan 3y ago

Tried out the instructions from the article on a tiny Bevy project, and compared it to a "normal" build: > cargo build --release 23.93s user 22.85s system 66% cpu 1:09.88 total > cargo +nightly build -Zcodegen-backend 23.52s user 21.98s system 68% cpu 1:06.86 total Seems just marginally faster than a normal release build. Wonder if there is something particular with Bevy that makes this so? The author of the article mentions 40% difference in build speed, but I'm not seeing anything near that. Edit: just realized I'm caching my release builds with sccache and a local NAS, hence the release builds being as fast as Cranelift+debug builds. Trying it again with just debug builds and without any caching: > cargo +nightly build 1997.35s user 200.38s system 1878% cpu 1:57.02 total > cargo +nightly build -Zcodegen-backend 280.96s user 73.06s system 657% cpu 53.850 total Definitely an improvement once I realized what I did wrong, about half the time spent compiling now :) Neat!

naasking 3y ago
Maybe your build is not limited by code generation, which seems like the only thing that changed here. There was a good thread recently about the variation in what slows down compilation: https://news.ycombinator.com/item?id=39721922 https://news.ycombinator.com/item?id=39721922
- diggan 3y ago
  Edited my comment now, forgot I was caching the release builds with sccache so wasn't actually compiling all the units, but fetching a lot of them instead :/
  - vlovich123 3y ago
    Which speaks to maybe that cargo should just ship with sccache turned on by default so that the “normal” experience for developing Rust has this seamless experience. Intelligent caching should always win. I’d like to see rustc get sccache integration that works at the MIR level too so that changing something that doesn’t change the code gen meaningfully still gets a cached response (e.g. changing some comments/whitespace, moving functions around, etc). Even cooler would be if LLVM itself could also cache internal expensive parts of compilation and optimization across process instances. That would make a huge impact in cutting down incremental builds.
    - SkiFire13 3y ago
      > I’d like to see rustc get sccache integration that works at the MIR level too so that changing something that doesn’t change the code gen meaningfully still gets a cached response (e.g. changing some comments/whitespace, moving functions around, etc). Isn't incremental compilation already like that?
deleted 3y ago
[deleted]
kapilsinha 3y ago
Is that Bevy project open-source by any chance? I'd love to it out myself
- doctor_phil 3y ago
  Bevyengine is open source and very findable by most search engines. Here is a direct link: https://github.com/bevyengine/bevy https://github.com/bevyengine/bevy
  - deleted 3y ago
    [deleted]
  - kapilsinha 3y ago
    Ah yep I'm aware of that. Bevy is a framework/engine that devs built on top of. I was referring to the project that OP has built on top of Bevy
bdhcuidbebe 3y ago
cache on a nas would limit cache speed to network speed. 1gbit is just about 125 megabytes/sec, while you can get a nvme disc with 4000+ megabytes/sec speed. so consider running sccache locally or just disable it for better build performance

by diggan 3y ago

naasking 3y ago

Maybe your build is not limited by code generation, which seems like the only thing that changed here. There was a good thread recently about the variation in what slows down compilation: https://news.ycombinator.com/item?id=39721922 https://news.ycombinator.com/item?id=39721922

diggan 3y ago
Edited my comment now, forgot I was caching the release builds with sccache so wasn't actually compiling all the units, but fetching a lot of them instead :/
- vlovich123 3y ago
  Which speaks to maybe that cargo should just ship with sccache turned on by default so that the “normal” experience for developing Rust has this seamless experience. Intelligent caching should always win. I’d like to see rustc get sccache integration that works at the MIR level too so that changing something that doesn’t change the code gen meaningfully still gets a cached response (e.g. changing some comments/whitespace, moving functions around, etc). Even cooler would be if LLVM itself could also cache internal expensive parts of compilation and optimization across process instances. That would make a huge impact in cutting down incremental builds.
  - SkiFire13 3y ago
    > I’d like to see rustc get sccache integration that works at the MIR level too so that changing something that doesn’t change the code gen meaningfully still gets a cached response (e.g. changing some comments/whitespace, moving functions around, etc). Isn't incremental compilation already like that?

deleted 3y ago

[deleted]

kapilsinha 3y ago

Is that Bevy project open-source by any chance? I'd love to it out myself

doctor_phil 3y ago
Bevyengine is open source and very findable by most search engines. Here is a direct link: https://github.com/bevyengine/bevy https://github.com/bevyengine/bevy
- deleted 3y ago
  [deleted]
- kapilsinha 3y ago
  Ah yep I'm aware of that. Bevy is a framework/engine that devs built on top of. I was referring to the project that OP has built on top of Bevy

bdhcuidbebe 3y ago

cache on a nas would limit cache speed to network speed. 1gbit is just about 125 megabytes/sec, while you can get a nvme disc with 4000+ megabytes/sec speed. so consider running sccache locally or just disable it for better build performance