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

Decouple serde from its derive crate #65

Merged
merged 1 commit into from
Aug 27, 2023
Merged

Conversation

CryZe
Copy link
Contributor

@CryZe CryZe commented Aug 27, 2023

By not activating the derive feature on serde, the compilation speed can be improved by a lot. This is because serde can then compile in parallel to serde_derive, allowing it to finish compilation possibly even before serde_derive, unblocking all the crates waiting for serde to start compiling much sooner.

As it turns out the main deciding factor for how long the compile time of a project is, is primarly determined by the depth of dependencies rather than the width. In other words, a crate's compile times aren't affected by how many crates it depends on, but rather by the longest chain of dependencies that it needs to wait on. In many cases serde is part of that long chain, as it is part of a long chain if the derive feature is active:

proc-macro2 compile build script > proc-macro2 run build script > proc-macro2 > quote > syn > serde_derive > serde > serde_json (or any crate that depends on serde)

By decoupling it from serde_derive, the chain is shortened and compile times get much better.

Check this issue for a deeper elaboration:
serde-rs/serde#2584

For samply I'm seeing a reduction from 5.43s to 3.70s when compiling fxprof-processed-profile in release mode.

image

The impact is even larger for crates that depend on fxprof-processed-profile such as wasmtime.

By not activating the `derive` feature on `serde`, the compilation speed
can be improved by a lot. This is because `serde` can then compile in
parallel to `serde_derive`, allowing it to finish compilation possibly
even before `serde_derive`, unblocking all the crates waiting for
`serde` to start compiling much sooner.

As it turns out the main deciding factor for how long the compile time of a
project is, is primarly determined by the depth of dependencies rather
than the width. In other words, a crate's compile times aren't affected
by how many crates it depends on, but rather by the longest chain of
dependencies that it needs to wait on. In many cases `serde` is part of
that long chain, as it is part of a long chain if the `derive` feature
is active:

`proc-macro2` compile build script > `proc-macro2` run build script >
`proc-macro2` > `quote` > `syn` > `serde_derive` > `serde` >
`serde_json` (or any crate that depends on serde)

By decoupling it from `serde_derive`, the chain is shortened and compile
times get much better.

Check this issue for a deeper elaboration:
serde-rs/serde#2584

For `samply` I'm seeing a reduction from 5.43s to 3.70s when compiling
`fxprof-processed-profile` in `release` mode.
Copy link
Owner

@mstange mstange left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a great result! Thank you!

@mstange mstange merged commit fc5b14c into mstange:main Aug 27, 2023
4 checks passed
@CryZe CryZe deleted the decouple-serde branch August 27, 2023 18:23
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

Successfully merging this pull request may close these issues.

2 participants