-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Don't duplicate the extern providers once for each crate #83649
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit cd7a011 with merge 47f4b9cd95f9b17537af3b251c2e5b97369c3acf... |
☀️ Try build successful - checks-actions |
Queued 47f4b9cd95f9b17537af3b251c2e5b97369c3acf with parent 3aedcf0, future comparison URL. |
Finished benchmarking try commit (47f4b9cd95f9b17537af3b251c2e5b97369c3acf): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
@bors r+ |
📌 Commit cd7a011 has been approved by |
☀️ Test successful - checks-actions |
This should give a small perf improvement for small crates by avoiding a memcpy of a pretty big struct for each loaded crate. In addition would be useful for replacing the sequential
CrateNum
everywhere with the hash basedStableCrateId
introduced in #81635, which would allow avoiding remapping ofCrateNum
's when loading crate metadata. While this PR is not strictly needed for that, it is necessary to prevent a performance loss due to it.I think this duplication was done in #40008 (which introduced the query system) to make it possible to compile multiple crates in a single session in the future. I think this is unlikely to be implemented any time soon. In addition this PR can easily be reverted if necessary to implement this.