-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Add Attribute::meta_kind #92294
Add Attribute::meta_kind #92294
Conversation
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 047275a with merge e2cda9a39cee49d9e3085509133f04ad8e34ca73... |
☀️ Try build successful - checks-actions |
Queued e2cda9a39cee49d9e3085509133f04ad8e34ca73 with parent f8abed9, future comparison URL. |
Finished benchmarking commit (e2cda9a39cee49d9e3085509133f04ad8e34ca73): comparison url. Summary: This change led to moderate relevant mixed results 🤷 in compiler performance.
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 @bors rollup=never |
Adding a query would be the right move as you suggested I think. Thanks for this improvement! @bors: r+ |
📌 Commit 047275a has been approved by |
⌛ Testing commit 047275a with merge 588e00bd33f4921e2c26eddd0bf853a1ddeb5969... |
💔 Test failed - checks-actions |
The job Click to see the possible cause of the failure (guessed by this bot)
|
@bors retry |
Not doing this was the reason using |
⌛ Testing commit 047275a with merge da30006ba96358bbfd605eda9e26bd83b03979db... |
💔 Test failed - checks-actions |
@bors retry network failure
|
⌛ Testing commit 047275a with merge db21c41f6cdbd2c07e8b3bc06e2acb447ffcba35... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
☀️ Test successful - checks-actions |
Finished benchmarking commit (c9cf9c6): 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 |
The
AttrItem::meta
function is being called on a lot of places, however almost always the caller is only interested in thekind
of the resultMetaItem
. Before, thepath
had to be cloned in order to get the kind, now it does not have to be.There is a larger related "problem". In a lot of places, something wants to know contents of attributes. This is accessed through
Attribute::meta_item_list
, which callsAttrItem::meta
(nowAttrItem::meta_kind
), among other methods. When this function is called, the meta item list has to be recreated from scratch. Everytime something asks a simple question (like is this item/list of attributes#[doc(hidden)]
?), the tokens of the attribute(s) are cloned, parsed and the results are allocated on the heap. That seems really unnecessary. What would be the best way to cache this? Turnmeta_item_list
into a query perhaps? Related PR: #92227r? rust-lang/rustdoc