Add fast path to `is_descendant_of` by camsteffen · Pull Request #91043 · rust-l...
source link: https://github.com/rust-lang/rust/pull/91043
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
New issue
Add fast path to is_descendant_of
#91043
Conversation
No description provided.
r? @jackh726
(rust-highfive has picked a reviewer for you, use r? to override)
I think we have an invariant that either expn_id == ExpnId::root()
or expn_id.krate == self.expn_data(expn_id).parent.krate
? I'm not sure that it always hold and that we enforce it. This would allow another fast path if expn_id.krate != ancestor.krate
.
I don't think that is true because a macro can have a nested macro call to an external crate?
Macros are expanded from the outer in. ExpnData::parent
tracks where the code ends up once expanded, def_site
tracks where it was written (possibly in an upstream crate) and call_site
where the macro call was written (possibly in a downstream crate).
Hence, even if the nested macro call is to a macro defined in an external crate, this nested macro call is expanded into the crate its parent was expanded into.
Actually, we check that expn_data.parent.krate == LOCAL_CRATE
when we assign a LocalExpnId
.
Okay I think I get it, tell me if this sounds right. A stack of nested macro calls are all triggered by one outermost macro call in a particular crate. All the expansions in the stack belong to that crate.
Should I modify HygieneData::is_descendant_of
too?
Indeed, we should probably make every caller benefit from the optimization.
changed the title
Add fast path to ExpnId::is_descendant
Add fast path to is_descendant_of
Whoops.
@petrochenkov let me know if your self-assignment was a mistake and I can review
expn_id.krate == self.expn_data(expn_id).parent.krate
?
That's not necessarily true if the parent is a root because we don't yet preserve krate IDs for root expansions, but otherwise this should be true.
I'd add an assert for this to the ExpnData
-creating function, if possible.
@jackh726
I usually add myself as a second reviewer if I want to be aware of the changes, feel free to review.
(Please don't forget to run perf.)
Awaiting bors try build completion.
@rustbot label: +S-waiting-on-perf
Try build successful - checks-actions
Build commit: 8cf5997 (8cf5997459fd458031256a1986c32a922e0d6c0a
)
Finished benchmarking commit (8cf5997): comparison url.
Summary: This change led to small relevant mixed results in compiler performance.
- Small improvement in instruction counts (up to -1.1% on
incr-unchanged
builds ofwg-grammar
) - Small regression in instruction counts (up to 0.5% on
incr-patched: println
builds ofstyle-servo
)
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. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.
Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged
along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.
@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression
Looks like a minor improvement.
Could you add
- an assert checking parent crate equality to
fn register_expn_id
- comments to both versions of
fn is_descendant_of
telling that the start code is a fast path that allows to avoid taking a lock / going in to the loop below.
I also changed a while
to loop
since I think it's more readable.
@rustbot ready
I don't think I know this code enough to actually r+ this, so I'll defer to @petrochenkov.
With that being said, the changes here seem okay to me.
@@ -1223,6 +1240,7 @@ pub fn register_expn_id(
data: ExpnData,
hash: ExpnHash,
) -> ExpnId {
debug_assert!(data.parent == ExpnId::root() || krate == data.parent.krate);
Should this be a regular assert?
Seems fine as is, the assert will be removed anyway when root expansions start keeping their crate IDs.
@bors r+
Commit ac8d514 has been approved by petrochenkov
Test successful - checks-actions
Approved by: petrochenkov
Pushing 44723c5 to master...
Finished benchmarking commit (44723c5): 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.
@rustbot label: -perf-regression
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Successfully merging this pull request may close these issues.
None yet
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK