Speed up `Parser::expected_tokens` #133793

nnethercote · 2024-12-03T09:21:43Z

The constant pushing/clearing of Parser::expected_tokens during parsing is slow. This PR speeds it up greatly.

r? @estebank

nnethercote · 2024-12-03T09:21:55Z

@bors try @rust-timer queue

…, r=<try> Speed up `Parser::expected_tokens` r? `@ghost`

bors · 2024-12-03T09:23:07Z

⌛ Trying commit 0133601 with merge 4e6952e...

bors · 2024-12-03T11:07:22Z

☀️ Try build successful - checks-actions
Build commit: 4e6952e (4e6952e2fa4367d9a5ef87505fa18f0dd3fedcc4)

rust-timer · 2024-12-03T13:34:53Z

Finished benchmarking commit (4e6952e): comparison URL.

Overall result: ✅ improvements - no action needed

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
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.9%	[-2.4%, -0.2%]	211
Improvements ✅ (secondary)	-0.8%	[-2.6%, -0.1%]	101
All ❌✅ (primary)	-0.9%	[-2.4%, -0.2%]	211

Max RSS (memory usage)

Results (primary -1.2%, secondary 1.6%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.5%	[0.5%, 0.5%]	1
Regressions ❌ (secondary)	2.9%	[0.9%, 5.4%]	3
Improvements ✅ (primary)	-2.1%	[-2.3%, -1.8%]	2
Improvements ✅ (secondary)	-2.2%	[-2.2%, -2.2%]	1
All ❌✅ (primary)	-1.2%	[-2.3%, 0.5%]	3

Cycles

Results (primary -1.5%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.5%	[-1.5%, -1.5%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.5%	[-1.5%, -1.5%]	2

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 767.333s -> 766.554s (-0.10%)
Artifact size: 332.08 MiB -> 332.14 MiB (0.02%)

Because the `Token` type is similar to but different to the `TokenType` type, and the difference is important, so we want to avoid confusion.

The most significant is `check_keyword`: it now only pushes to `expected_token_types` if the keyword check fails, which matches how all the other `check` methods work. The remainder are just tweaks to make these methods more consistent with each other.

This is a naming convention used in a handful of spots in the parser for delimiters. It confused me when I first saw it a long time ago, and I've never liked it. A web search says "Bra-ket notation" exists in linear algebra but the terminology has zero prior use in a programming context, as far as I can tell. This commit changes it to `open`/`close`, which is consistent with the rest of the compiler.

rustbot · 2024-12-04T05:40:54Z

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

nnethercote · 2024-12-04T05:42:51Z

Best reviewed one commit at a time.

Let's re-run perf just to be sure: @bors try @rust-timer queue

…, r=<try> Speed up `Parser::expected_tokens` The constant pushing/clearing of `Parser::expected_tokens` during parsing is slow. This PR speeds it up greatly. r? `@estebank`

bors · 2024-12-04T06:13:47Z

⌛ Trying commit f5482df with merge 26060e63f06a4dcd55fc0757eb5b0bdc8136ed3b...

estebank · 2024-12-04T06:14:54Z

compiler/rustc_parse/src/parser/diagnostics.rs


-    pub(super) fn consume_block(&mut self, delim: Delimiter, consume_close: ConsumeClosingDelim) {
+    pub(super) fn consume_block(
+        &mut self,
+        open: ExpTokenPair<'_>,
+        close: ExpTokenPair<'_>,
+        consume_close: ConsumeClosingDelim,
+    ) {


Sad to see the delimiters go away and get denormalized, but I get it.

estebank · 2024-12-04T06:18:06Z

compiler/rustc_parse/src/parser/token_type.rs

+/// We really want to keep the number of variants to 128 or fewer, sot that
+/// `TokenTypeSet` can be implemented with a `u128`.


On the one hand, we should be able to do so. On the other, I can see this becoming a point of contention with t-lang in the medium future if we push back on a feature for this reason :)

The 17 asm symbols would be a good place to cut things down if necessary. I'm a bit annoyed that they are even in there; so many of them for such a rare use case.

estebank · 2024-12-04T06:21:28Z

compiler/rustc_parse/src/parser/token_type.rs

+        // This assertion will detect if this method and the type definition get out of sync.
+        assert_eq!(token_type as u32, val);
+        token_type


Can't the function just be the as cast with a <=104 check?

No. You can convert a C-style enum to an integer with as, but you can't convert in the other direction, e.g. as per this StackOverflow answer. There are proc macros to do it, but that answer pointed out an alternative that is suitable here: transmute is fine so long as the enum is repr(uN) for some value of N. So I will do that with repr(u8), which will cut over 100 lines of code, yay.

estebank · 2024-12-04T06:23:35Z

compiler/rustc_parse/src/parser/token_type.rs

+// bogus "macro-expanded `macro_export` macros from the current crate cannot be
+// referred to by absolute paths" error, ugh. See #52234.
+#[cfg_attr(rustfmt, rustfmt::skip)]
+macro_rules! exp {


Just to make sure I understand, exp and Exp* stands for "expected"?

estebank · 2024-12-04T06:26:47Z

compiler/rustc_parse/src/parser/token_type.rs

+    (Plus)           => { exp!(@binop, Plus) };
+    (Minus)          => { exp!(@binop, Minus) };
+    (Star)           => { exp!(@binop, Star) };
+    (And)            => { exp!(@binop, And) };
+    (Or)             => { exp!(@binop, Or) };


I'm half tempted at making this support things like exp!(+) and exp!(?) 😈

I was initially going to do that. At one point I had exp!(_) instead of exp!(Underscore) and I was using actual keywords like exp!(if) instead of exp!(If). A lot of tokens can be made to work but all the delimiters absolutely cannot, so I decided to use StudlyCaps names for all of them :)

estebank · 2024-12-04T06:29:15Z

I'll finish reviewing tomorrow

bors · 2024-12-04T07:56:59Z

☀️ Try build successful - checks-actions
Build commit: 26060e6 (26060e63f06a4dcd55fc0757eb5b0bdc8136ed3b)

The parser pushes a `TokenType` to `Parser::expected_token_types` on every call to the various `check`/`eat` methods, and clears it on every call to `bump`. Some of those `TokenType` values are full tokens that require cloning and dropping. This is a *lot* of work for something that is only used in error messages and it accounts for a significant fraction of parsing execution time. This commit overhauls `TokenType` so that `Parser::expected_token_types` can be implemented as a bitset. This requires changing `TokenType` to a C-style parameterless enum, and adding `TokenTypeSet` which uses a `u128` for the bits. (The new `TokenType` has 105 variants.) The new types `ExpTokenPair` and `ExpKeywordPair` are now arguments to the `check`/`eat` methods. This is for maximum speed. The elements in the pairs are always statically known; e.g. a `token::BinOp(token::Star)` is always paired with a `TokenType::Star`. So we now compute `TokenType`s in advance and pass them in to `check`/`eat` rather than the current approach of constructing them on insertion into `expected_token_types`. Values of these pair types can be produced by the new `exp!` macro, which is used at every `check`/`eat` call site. The macro is for convenience, allowing any pair to be generated from a single identifier. The ident/keyword filtering in `expected_one_of_not_found` is no longer necessary. It was there to account for some sloppiness in `TokenKind`/`TokenType` comparisons. The existing `TokenType` is moved to a new file `token_type.rs`, and all its new infrastructure is added to that file. There is more boilerplate code than I would like, but I can't see how to make it shorter.

rust-timer · 2024-12-04T09:56:15Z

Finished benchmarking commit (26060e6): comparison URL.

Overall result: ✅ improvements - no action needed

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
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.9%	[-2.4%, -0.2%]	213
Improvements ✅ (secondary)	-0.8%	[-2.7%, -0.1%]	98
All ❌✅ (primary)	-0.9%	[-2.4%, -0.2%]	213

Max RSS (memory usage)

Results (primary -0.9%, secondary 0.8%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.4%	[0.4%, 0.4%]	1
Regressions ❌ (secondary)	1.7%	[0.7%, 2.3%]	3
Improvements ✅ (primary)	-2.2%	[-2.2%, -2.2%]	1
Improvements ✅ (secondary)	-1.8%	[-1.8%, -1.8%]	1
All ❌✅ (primary)	-0.9%	[-2.2%, 0.4%]	2

Cycles

Results (primary 1.4%, secondary 2.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.4%	[0.9%, 2.5%]	22
Regressions ❌ (secondary)	2.4%	[1.3%, 3.2%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.4%	[0.9%, 2.5%]	22

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 767.635s -> 770.294s (0.35%)
Artifact size: 330.89 MiB -> 330.89 MiB (0.00%)

nnethercote · 2024-12-04T09:57:48Z

I updated, adding a new commit that uses transmute for the int-to-TokenType conversion.

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 3, 2024

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 3, 2024

bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 3, 2024

Auto merge of rust-lang#133793 - nnethercote:speed-up-expected_tokens…

4e6952e

…, r=<try> Speed up `Parser::expected_tokens` r? `@ghost`

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 3, 2024

nnethercote added 3 commits December 4, 2024 13:45

Rename Parser::expected_tokens as Parser::expected_token_types.

93403de

Because the `Token` type is similar to but different to the `TokenType` type, and the difference is important, so we want to avoid confusion.

nnethercote force-pushed the speed-up-expected_tokens branch from 0133601 to f5482df Compare December 4, 2024 05:40

nnethercote marked this pull request as ready for review December 4, 2024 05:40

rustbot assigned estebank Dec 4, 2024

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 4, 2024

estebank reviewed Dec 4, 2024

View reviewed changes

estebank approved these changes Dec 4, 2024

View reviewed changes

This comment has been minimized.

Sign in to view

nnethercote added 2 commits December 4, 2024 20:54

Use transmute to convert an integer to TokenType.

a353d56

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Dec 4, 2024

nnethercote force-pushed the speed-up-expected_tokens branch from f5482df to a353d56 Compare December 4, 2024 09:57

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Speed up `Parser::expected_tokens` #133793

Speed up `Parser::expected_tokens` #133793

nnethercote commented Dec 3, 2024 •

edited

Loading

nnethercote commented Dec 3, 2024

This comment has been minimized.

bors commented Dec 3, 2024

This comment has been minimized.

bors commented Dec 3, 2024

This comment has been minimized.

rust-timer commented Dec 3, 2024

rustbot commented Dec 4, 2024

nnethercote commented Dec 4, 2024

This comment has been minimized.

bors commented Dec 4, 2024

estebank Dec 4, 2024

estebank Dec 4, 2024

nnethercote Dec 4, 2024 •

edited

Loading

estebank Dec 4, 2024

nnethercote Dec 4, 2024

estebank Dec 4, 2024

nnethercote Dec 4, 2024

estebank Dec 4, 2024

nnethercote Dec 4, 2024

estebank commented Dec 4, 2024

bors commented Dec 4, 2024

This comment has been minimized.

rust-timer commented Dec 4, 2024

nnethercote commented Dec 4, 2024

		/// We really want to keep the number of variants to 128 or fewer, sot that
		/// `TokenTypeSet` can be implemented with a `u128`.

Speed up Parser::expected_tokens #133793

Are you sure you want to change the base?

Speed up Parser::expected_tokens #133793

Conversation

nnethercote commented Dec 3, 2024 • edited Loading

nnethercote commented Dec 3, 2024

This comment has been minimized.

bors commented Dec 3, 2024

This comment has been minimized.

bors commented Dec 3, 2024

This comment has been minimized.

rust-timer commented Dec 3, 2024

Overall result: ✅ improvements - no action needed

rustbot commented Dec 4, 2024

nnethercote commented Dec 4, 2024

This comment has been minimized.

bors commented Dec 4, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nnethercote Dec 4, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

estebank commented Dec 4, 2024

bors commented Dec 4, 2024

This comment has been minimized.

rust-timer commented Dec 4, 2024

Overall result: ✅ improvements - no action needed

nnethercote commented Dec 4, 2024

Speed up `Parser::expected_tokens` #133793

Speed up `Parser::expected_tokens` #133793

nnethercote commented Dec 3, 2024 •

edited

Loading

nnethercote Dec 4, 2024 •

edited

Loading