-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Improve incremental compile speed on webrender_api
#59650
Labels
A-incr-comp
Area: Incremental compilation
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
I-compiletime
Issue: Problems and improvements with respect to compile times.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
Here is some edited Cachegrind output from the abovementioned workload. I removed various entries that didn't obviously relate to
|
jonas-schievink
added
A-incr-comp
Area: Incremental compilation
I-compiletime
Issue: Problems and improvements with respect to compile times.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
labels
Apr 2, 2019
#59820 helps some more. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-incr-comp
Area: Incremental compilation
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
I-compiletime
Issue: Problems and improvements with respect to compile times.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
This was originally filed as a
rustc-perf
issue, but I'm moving it here because it's really a rustc issue.The workload in question:
In
rustc-perf
parlance, that is a "CleanIncr" build.The 5692 lines of rust code in
webrender_api
expand to 85511 withcargo expand
, largely due toserde
, and the expansion phase dominates. So it's basically a stress test for proc macro expansion.#59476 helped a tiny bit. #59507 helped more. The major remaining source of inefficiency is
libproc_macro
's buffer for communicating between client and server.Buffer::write_all
is called more than a million times, almost always for a single byte, mostly due to uleb128 encoding of integers. @eddyb said they would try to improve that code. I estimate this could save another 10%, maybe more.The text was updated successfully, but these errors were encountered: