CryZe opened PR #6917 from CryZe:decouple-serde-derive
to bytecodealliance:main
:
By not activating the
derive
feature onserde
, the compilation speed can be improved by a lot. This is becauseserde
can then compile in parallel toserde_derive
, allowing it to finish compilation possibly even beforeserde_derive
, unblocking all the crates waiting forserde
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 thederive
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:
https://github.com/serde-rs/serde/issues/2584For
wasmtime
I'm seeing a reduction from 24.75s to 22.45s when compiling inrelease
mode. This is because wasmtime throughgimli
has a dependency onindexmap
which can only start compiling whenserde
is finished, which you want to happen as early as possible so some of wasmtime's dependencies can start compiling.To measure the full effect, the dependencies can't by themselves activate the
derive
feature. I've upstreamed a patch forfxprof-processed-profile
which was the only dependency that activated it forwasmtime
(not yet published to crates.io).wasmtime-cli
and co. may need patches for their dependencies to see a similar improvement.<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
CryZe requested fitzgen for a review on PR #6917.
CryZe requested wasmtime-compiler-reviewers for a review on PR #6917.
CryZe requested wasmtime-default-reviewers for a review on PR #6917.
CryZe requested wasmtime-core-reviewers for a review on PR #6917.
fitzgen submitted PR review:
Thanks! One comment below.
fitzgen submitted PR review:
Thanks! One comment below.
fitzgen created PR review comment:
Can you avoid this version bump in this PR? IIUC, decoupling the dependencies is orthogonal from upgrading them, and upgrading dependencies requires a core team member do an audit, which will slow things down here.
CryZe created PR review comment:
I did the bump, because
serde
itself ensures thatserde_derive
is always a compatible version since https://github.com/serde-rs/serde/releases/tag/v1.0.186
CryZe submitted PR review.
CryZe edited PR review comment.
CryZe updated PR #6917.
fitzgen submitted PR review:
Thanks!
fitzgen merged PR #6917.
Last updated: Dec 23 2024 at 12:05 UTC