Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reducing Compile Time #531

Open
Plecra opened this issue Feb 7, 2022 · 8 comments
Open

Reducing Compile Time #531

Plecra opened this issue Feb 7, 2022 · 8 comments

Comments

@Plecra
Copy link

Plecra commented Feb 7, 2022

Description

It takes an awful lot of work to compile feather. It'd be nice to see if there's any fat we can trim.

I'm starting with using cargo-tree to check out the dependency tree.

  • target-lexicon:0.11.2 may be able to be updated to 0.12.2, removing duplication (aw shucks, it wasn't in the main build)
@Plecra
Copy link
Author

Plecra commented Feb 8, 2022

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.

@Plecra Plecra mentioned this issue Feb 8, 2022
6 tasks
@Iaiao
Copy link
Contributor

Iaiao commented Feb 8, 2022

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

@Plecra
Copy link
Author

Plecra commented Feb 8, 2022

Sounds like a nice idea :)

@Plecra Plecra mentioned this issue Feb 8, 2022
6 tasks
@Plecra
Copy link
Author

Plecra commented Feb 8, 2022

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
Copy link
Member

PauMAVA commented Feb 9, 2022

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
Copy link
Author

Plecra commented Feb 9, 2022

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)

@ClSlaid
Copy link

ClSlaid commented May 10, 2022

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/

@Nilstrieb
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants