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

Avoid many CrateConfig clones. #37161

Merged
merged 1 commit into from
Oct 19, 2016
Merged

Conversation

nnethercote
Copy link
Contributor

This commit changes ExtCtx::cfg() so it returns a CrateConfig
reference instead of a clone. As a result, it also changes all of the
cfg() callsites to explicitly clone... except one, because the commit
also changes macro_parser::parse() to take &CrateConfig. This is
good, because that function can be hot, and CrateConfig is expensive
to clone.

This change almost halves the number of heap allocations done by rustc
for html5ever in rustc-benchmarks suite, which makes compilation 1.20x
faster.

r? @nrc

This commit changes `ExtCtx::cfg()` so it returns a `CrateConfig`
reference instead of a clone. As a result, it also changes all of the
`cfg()` callsites to explicitly clone... except one, because the commit
also changes `macro_parser::parse()` to take `&CrateConfig`. This is
good, because that function can be hot, and `CrateConfig` is expensive
to clone.

This change almost halves the number of heap allocations done by rustc
for `html5ever` in rustc-benchmarks suite, which makes compilation 1.20x
faster.
@eddyb
Copy link
Member

eddyb commented Oct 14, 2016

If we can't use references in some cases but the data is always immutable, why not wrap it in Rc?

@nnethercote
Copy link
Contributor Author

I tried making it a &'a CrateConfig throughout, similar to sess, but there were some tricky bits that I couldn't work get to work. And this change is very simple and gets 99% of the benefit.

@eddyb
Copy link
Member

eddyb commented Oct 14, 2016

I mean, either Rc<CrateConfig> or using Rc inside CrateConfig should be at most as invasive, if not less, and handle all the cases so no data is ever cloned. This may improve a lot of crates' expansion.

@nnethercote
Copy link
Contributor Author

This may improve a lot of crates' expansion.

I don't understand what you mean by this. Can you elaborate? Thanks.

@eddyb
Copy link
Member

eddyb commented Oct 14, 2016

I mean that there's still many clones and some of them may contribute to expansion times in other crates.
In principle, if fixing all cases is possible, it should be done, instead of specializing for one profile.

@nnethercote
Copy link
Contributor Author

In principle, if fixing all cases is possible, it should be done, instead of specializing for one profile.

Premature optimization, don't let perfect be the enemy of good, etc, etc. Let's see what @nrc thinks.

@eddyb
Copy link
Member

eddyb commented Oct 14, 2016

Hey I thought the motto of Rust was "Don't let 'good enough' be the enemy of 'perfect'" 😆

@nnethercote
Copy link
Contributor Author

Hey I thought the motto of Rust was "Don't let 'good enough' be the enemy of 'perfect'" 😆

I know you are at least partly joking, but I will respond seriously: an uncompromising attitude like that makes sense for aspects of Rust's design as a language -- e.g. no compromise on memory safety -- but I don't think the same attitude is necessarily relevant or helpful when it comes to the compiler implementation.

@nrc
Copy link
Member

nrc commented Oct 18, 2016

@bors: r+

It would be interesting to try @eddyb's Rc approach, but this PR makes things strictly better than they are at the moment, so no reason not to land it.

@bors
Copy link
Contributor

bors commented Oct 18, 2016

📌 Commit 029dcee has been approved by nrc

@eddyb
Copy link
Member

eddyb commented Oct 18, 2016

@nrc This PR adds clone calls all over the place, using Rc would be simpler, that's why I mentioned it.

eddyb added a commit to eddyb/rust that referenced this pull request Oct 19, 2016
Avoid many CrateConfig clones.

This commit changes `ExtCtx::cfg()` so it returns a `CrateConfig`
reference instead of a clone. As a result, it also changes all of the
`cfg()` callsites to explicitly clone... except one, because the commit
also changes `macro_parser::parse()` to take `&CrateConfig`. This is
good, because that function can be hot, and `CrateConfig` is expensive
to clone.

This change almost halves the number of heap allocations done by rustc
for `html5ever` in rustc-benchmarks suite, which makes compilation 1.20x
faster.

r? @nrc
eddyb added a commit to eddyb/rust that referenced this pull request Oct 19, 2016
Avoid many CrateConfig clones.

This commit changes `ExtCtx::cfg()` so it returns a `CrateConfig`
reference instead of a clone. As a result, it also changes all of the
`cfg()` callsites to explicitly clone... except one, because the commit
also changes `macro_parser::parse()` to take `&CrateConfig`. This is
good, because that function can be hot, and `CrateConfig` is expensive
to clone.

This change almost halves the number of heap allocations done by rustc
for `html5ever` in rustc-benchmarks suite, which makes compilation 1.20x
faster.

r? @nrc
bors added a commit that referenced this pull request Oct 19, 2016
@bors bors merged commit 029dcee into rust-lang:master Oct 19, 2016
@nnethercote nnethercote deleted the no-cfg-cloning branch October 19, 2016 10:00
@nnethercote
Copy link
Contributor Author

It would be interesting to try @eddyb's Rc approach

@jseyfried ended up removing all the CrateConfig clones a different (and better) way in #37431.

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.

4 participants