Skip to content

Conversation

nnethercote
Copy link
Contributor

@nnethercote nnethercote commented Oct 7, 2025

A follow-up to #147293, where I attempted and mostly failed to make things faster again, but I found a few cleanups worth doing.

r? @ghost

Two functions take arguments of this type, but the `Option` is always
`Some`, so we can just pass `&MarkFrame<'_>` instead.
Because it's only ever used for inserting red. (`None` is only used as a
starting value, and `Green` is inserted by `try_mark_green` and
friends.)
Currently it's binary, either `Green` or `Red`. But it's almost always
used within an `Option`. So it's a bit neater, and possibly slightly
faster, to make it tri-value with `Unknown` as a first-class variant.
@rustbot rustbot added A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 7, 2025
@nnethercote
Copy link
Contributor Author

@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

rust-bors bot added a commit that referenced this pull request Oct 7, 2025
@rust-bors

This comment has been minimized.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Oct 7, 2025
}
}
Red,
Unknown,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is Unknown last here, while COMORESSED_UNKNOWN is less than COMPRESSED_RED?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have rearranged things so the order is always green, red, unknown.

DepNodeColor::Red,
);
colors.insert_red(SerializedDepNodeIndex::from_u32(
DepNodeIndex::FOREVER_RED_NODE.as_u32(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we introduce a SERIALIZED_RED constant?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure. Feels orthogonal to this PR.

@rust-bors
Copy link

rust-bors bot commented Oct 7, 2025

☀️ Try build successful (CI)
Build commit: 40c8f48 (40c8f48fa9837632a61cd1bb1dac6118e2d93e1b, parent: 3d8c1c1fc077d04658de63261d8ce2903546db13)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (40c8f48): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.6% [-1.5%, -0.2%] 96
Improvements ✅
(secondary)
-0.6% [-1.1%, -0.2%] 46
All ❌✅ (primary) -0.6% [-1.5%, -0.2%] 96

Max RSS (memory usage)

Results (secondary 2.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

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

Cycles

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

Binary size

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

Bootstrap: 472.01s -> 471.833s (-0.04%)
Artifact size: 388.39 MiB -> 388.35 MiB (-0.01%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Oct 7, 2025
@nnethercote
Copy link
Contributor Author

Cool, once again the CI results are better than what I saw locally.

The most common `get` case is green. This commit changes `get` to use
use `if`/`else` instead of match, so that getting green requires one
comparison instead of two.
It uses a different implementation depending on whether the compiler
front-end is running single-threaded or multi-threaded. The two
implementations are equivalent and I think the multi-threaded one
expresses the intent more clearly, and I imagine the perf is similar. So
this commit removes the single-threaded code.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants