-
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
Speed up TokenCursor
#96210
Speed up TokenCursor
#96210
Conversation
This makes it more like `CursorRef::next_with_spacing`. There is no performance effect, just a consistency improvement.
They both have a single call site.
It has a single call site.
And likewise for the inlined variants. I did this for simplicity, but interesting it was a performance win as well.
In particular, avoid wrapping a token within `TokenTree::Token` and then immediately matching it and returning the token within. Just return the token immediately.
This will facilitate the change in the next commit. `boolean` arguments aren't great, but the function is only used in three places within this one file.
Instead of letting the next iteration of the loop handle it.
Some local instruction count measurements:
The cycles counts are even better, e.g.:
|
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 36c7c829e99b3785de94e6113b4abb4ff0410e9c with merge efe204aef96605ab9df88a21434b2b571a770ede... |
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
Queued efe204aef96605ab9df88a21434b2b571a770ede with parent e2661ba, future comparison URL. |
Finished benchmarking commit (efe204aef96605ab9df88a21434b2b571a770ede): comparison url. Summary:
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 may lead to changes in compiler perf. @bors rollup=never Footnotes |
|
It's not hot, so shouldn't be within the always inlined part.
36c7c82
to
e0b2272
Compare
I have fixed the tidy error. Cachegrind indicates that the outsized wall-time speedup for |
The `DelimToken` here is `NoDelim`, which means the returned delim tokens will just be ignored by `Parser::bump()`. This commit changes things so the delim tokens won't be returned.
Because it's now always true.
The loop is there to handle a `NoDelim` open/close token. This commit changes `TokenCursor::inlined_next` so it never returns such a token. This is a performance win because the conditional test in `bump()` is removed. If the parser needs changing in the future to handle `NoDelim` tokens, then `inlined_next()` can easily be changed to return them.
if self.prev_token.kind == TokenKind::Eof { | ||
let msg = "attempted to bump the parser past EOF (may be stuck in a loop)"; | ||
self.span_bug(self.token.span, msg); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We 100% have seen this error, and relatively commonly, until relevant bugs in the parser were fixed.
But it was several years ago already.
Surprisingly, this is a non-trivial performance win.
This makes `CloseDelim` handling more like `OpenDelim` handling, which produces `OpenDelim` and pushes the stack at the same time. It requires some adjustment to `parse_token_tree` now that we don't remain within the frame after getting the `CloseDelim`.
This lets us clone just the parts within a `TokenTree` that need cloning, rather than the entire thing. This is a surprisingly large performance win, up to 4% on `async-std-1.10.0`.
e5d0a36
to
643e9f7
Compare
I have added two new commits. The first changes how
|
@bors r+ |
📌 Commit 643e9f7 has been approved by |
⌛ Testing commit 643e9f7 with merge e35a533fb398e98b318502c2920f82e110aad604... |
💔 Test failed - checks-actions |
@bors retry "The hosted runner: GitHub Actions 5 lost communication with the server" on dist-aarch64-apple |
☀️ Test successful - checks-actions |
Finished benchmarking commit (b04c532): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
Plus a few related clean-ups.
r? @petrochenkov