-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Remove redundant Span
in QueryJobInfo
#88567
Conversation
Previously, `QueryJobInfo` was composed of two parts: a `QueryInfo` and a `QueryJob`. However, both `QueryInfo` and `QueryJob` have a `span` field, which seem to be the same. So, the `span` was recorded twice. Now, `QueryJobInfo` is composed of a `QueryStackFrame` (the other field of `QueryInfo`) and a `QueryJob`. So, now, the `span` is only recorded once.
(rust-highfive has picked a reviewer for you, use r? to override) |
r? @cjgillot This may have a small improvement of compile-time memory usage, but it's likely to be quite small. Should I still mark this as rollup=never? |
The query infra is absurdly sensitive. |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 4553a4b with merge 1cfbf261628e807ec0ad3d020b373adc5494b811... |
☀️ Try build successful - checks-actions |
Queued 1cfbf261628e807ec0ad3d020b373adc5494b811 with parent ad3407f, future comparison URL. |
Finished benchmarking try commit (1cfbf261628e807ec0ad3d020b373adc5494b811): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. @bors rollup=never |
I'm not sure why it said there were no significant changes; instruction count is down by ~0.2% on several benchmarks; the only significant regression (according to the perf.rlo webpage) is 0.4% for |
This greatly increased max-rss for tuple-stress-doc for some reason. Not sure if it's spurious or not. |
<1% changes are not what I call significant :)
It's spurious, those code path are only used in incremental runs, and the regressed run is not incremental. @bors r+ rollup |
📌 Commit 4553a4b has been approved by |
Well, of course it's not a large improvement, but the web interface shows those changes as "relevant" which I would think would be similar to "significant" :) |
Rollup of 12 pull requests Successful merges: - rust-lang#88177 (Stabilize std::os::unix::fs::chroot) - rust-lang#88505 (Use `unwrap_unchecked` where possible) - rust-lang#88512 (Upgrade array_into_iter lint to include Deref-to-array types.) - rust-lang#88532 (Remove single use variables) - rust-lang#88543 (Improve closure dummy capture suggestion in macros.) - rust-lang#88560 (`fmt::Formatter::pad`: don't call chars().count() more than one time) - rust-lang#88565 (Add regression test for issue 83190) - rust-lang#88567 (Remove redundant `Span` in `QueryJobInfo`) - rust-lang#88573 (rustdoc: Don't panic on ambiguous inherent associated types) - rust-lang#88582 (Implement rust-lang#88581) - rust-lang#88589 (Correct doc comments inside `use_expr_visitor.rs`) - rust-lang#88592 (Fix ICE in const check) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Previously,
QueryJobInfo
was composed of two parts: aQueryInfo
anda
QueryJob
. However, bothQueryInfo
andQueryJob
have aspan
field, which seem to be the same. So, the
span
was recorded twice.Now,
QueryJobInfo
is composed of aQueryStackFrame
(the other fieldof
QueryInfo
) and aQueryJob
. So, now, thespan
is only recordedonce.