Reducing Compile Time

[Plecra]

Reducing Compile Time

[Plecra]

I have submitted #532, #533, #534, #535 and #536 to start addressing this. Each are small version changes which allow cargo to unify more of the dependencies, and reduce the output of cargo tree -d. Each change will only make a small effect, but changing crate versions is easy pickings.

[Nilstrieb]

Hey!

I was reading this issue and I wanted to let you know about a tool I recently created that I think maybe some of you can find useful. This is obviously complementary to all these optimizations that you are making and that are clearly good in order to reduce compile times of feather.

I had recently stumbled upon some painfully long compile times in some of my personal/work projects written in rust (especially those with lots of dependencies) and I decided to investigate a little about it. I found out that in most cases the overhead was caused by the disk.

I created a small cargo command called cargo-ramdisk that sets up a ramdisk in the target folder. By using this tool I have been able to reduce compile times A LOT. For example in one of my biggest projects:

Full Incremental
Without cargo-ramdisk 16m30s 4m30s
With cargo-ramdisk 1m30s 14.5s
The only "bad" thing about this tool is that every time you reboot your PC the incremental build will be lost. Also, this probably worked for me because I was compiling in WSL2 and there was some severe overhead. I have a M.2 SSD.

It's far from perfect (and has some known bugs) but I leave you a link to the repo if someone wants to check it out.

Thanks for contributing to feather!
@PauMAVA

I just came across this and saw that cargo-ramdisk gave you these huge speed improvements. I couldn't believe it and tried it myself on some project, and I didn't see any improvement, since, as expected, Rust compilation is not IO bound.

The speedup on your system is easily explainable by you compiling a project in WSL2 that was located in the windows filesystem, at which point compilation does become IO bound since WSL2<->Windows file system interop is incredibly slow. You should either keep the project in the WSL2 filesystem or compile from Windows.

[Iaiao]

Maybe we should add cargo-deny to our CI? (it warns about duplicated dependencies and some other things)

[ClSlaid]

That sounds fantastic! I'll certainly give it a try because this sounds like it'd be useful for all sorts of rust work.

What did this slow down looked like in the cargo profiler output? It's pointing fingers at the semantic analysis of a lot of the crates for me, which doesn't sound right if the problem is the disk :D (I suspect my compilation could be being bottlenecked by the memory capacity on my laptop)

This may be of help.
https://endler.dev/2020/rust-compile-times/

[Plecra]

Sounds like a nice idea :)

[Plecra]

I'm having a look at good targets to reduce compile time in -Z timings.

As always, syn is by far the worst offender. Any proc macro crates we can remove are going to be a bonus.

• wasmer pulls in a lot of long-running builds. We should explore making it a feature that's normally off for development builds. Also maybe look at comparing it to wasmtime.
• serde_with pulls in darling, and it's probably easy to drop
• making serde_derive configurable could help a lot with parallelism. With it, serde crates are blocked for 4m on my computer!
• the networking implementation can likely be written more simply without tokio but that'll take a decent amount of work.
• bitvec and slab aren't rlly necessary. they're being used as half-baked optimizations at the moment.
• itertools is easy to remove. it's barely being used
• trying to feature gate/remove ureq would be great too - it has a lot of unique dependencies.
  • maybe we can run in offline mode without ureq?

[PauMAVA]

Hey!

I was reading this issue and I wanted to let you know about a tool I recently created that I think maybe some of you can find useful. This is obviously complementary to all these optimizations that you are making and that are clearly good in order to reduce compile times of feather.

I had recently stumbled upon some painfully long compile times in some of my personal/work projects written in rust (especially those with lots of dependencies) and I decided to investigate a little about it. I found out that in most cases the overhead was caused by the disk.

I created a small cargo command called cargo-ramdisk that sets up a ramdisk in the target folder. By using this tool I have been able to reduce compile times A LOT. For example in one of my biggest projects:

	Full	Incremental
Without cargo-ramdisk	16m30s	4m30s
With cargo-ramdisk	1m30s	14.5s

The only "bad" thing about this tool is that every time you reboot your PC the incremental build will be lost. Also, this probably worked for me because I was compiling in WSL2 and there was some severe overhead. I have a M.2 SSD.

It's far from perfect (and has some known bugs) but I leave you a link to the repo if someone wants to check it out.

Thanks for contributing to feather!

[Plecra]

That sounds fantastic! I'll certainly give it a try because this sounds like it'd be useful for all sorts of rust work.

What did this slow down looked like in the cargo profiler output? It's pointing fingers at the semantic analysis of a lot of the crates for me, which doesn't sound right if the problem is the disk :D (I suspect my compilation could be being bottlenecked by the memory capacity on my laptop)