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? @saethlin

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
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.
@nnethercote
Copy link
Contributor Author

Let's re-run perf to make sure my changes didn't muck things up:

@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
@rust-bors
Copy link

rust-bors bot commented Oct 7, 2025

☀️ Try build successful (CI)
Build commit: bc91772 (bc917725191fb1f5aae04eeb24f8f246cfc5d80f, parent: d773bd07d63a74adcf25ea5f4aae986be94cac5e)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (bc91772): 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.4%, -0.2%] 100
Improvements ✅
(secondary)
-0.6% [-1.1%, -0.1%] 42
All ❌✅ (primary) -0.6% [-1.4%, -0.2%] 100

Max RSS (memory usage)

Results (secondary 1.7%)

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)
1.7% [1.4%, 2.0%] 2
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: 473.455s -> 472.567s (-0.19%)
Artifact size: 388.39 MiB -> 388.38 MiB (-0.00%)

@rustbot rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Oct 7, 2025
@nnethercote nnethercote marked this pull request as ready for review October 7, 2025 11:06
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 7, 2025
@nnethercote
Copy link
Contributor Author

Second CI perf run looks the same as the first. Good to go, I think.

@cjgillot
Copy link
Contributor

cjgillot commented Oct 7, 2025

Thanks!
@bors r+

@bors
Copy link
Collaborator

bors commented Oct 7, 2025

📌 Commit 19423b7 has been approved by cjgillot

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 7, 2025
bors added a commit that referenced this pull request Oct 7, 2025
`DepNodeColor` tweaks

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? `@saethlin`
@bors
Copy link
Collaborator

bors commented Oct 7, 2025

⌛ Testing commit 19423b7 with merge 68070eb...

@bors
Copy link
Collaborator

bors commented Oct 7, 2025

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 7, 2025
@nnethercote
Copy link
Contributor Author

@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 7, 2025
@bors
Copy link
Collaborator

bors commented Oct 8, 2025

⌛ Testing commit 19423b7 with merge 5767910...

@bors
Copy link
Collaborator

bors commented Oct 8, 2025

☀️ Test successful - checks-actions
Approved by: cjgillot
Pushing 5767910 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 8, 2025
@bors bors merged commit 5767910 into rust-lang:master Oct 8, 2025
12 checks passed
@rustbot rustbot added this to the 1.92.0 milestone Oct 8, 2025
Copy link
Contributor

github-actions bot commented Oct 8, 2025

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 4fd3181 (parent) -> 5767910 (this PR)

Test differences

Show 2 test diffs

2 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 5767910cbcc9d199bf261a468574d45aa3857599 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. dist-x86_64-apple: 7050.9s -> 9219.9s (30.8%)
  2. aarch64-apple: 9726.2s -> 7023.8s (-27.8%)
  3. dist-aarch64-msvc: 6622.2s -> 5349.6s (-19.2%)
  4. dist-apple-various: 3645.5s -> 4041.2s (10.9%)
  5. x86_64-gnu-miri: 4354.7s -> 4798.6s (10.2%)
  6. aarch64-gnu-llvm-20-2: 2437.0s -> 2668.0s (9.5%)
  7. dist-aarch64-apple: 7984.3s -> 7287.0s (-8.7%)
  8. dist-arm-linux-gnueabi: 4949.4s -> 5315.1s (7.4%)
  9. dist-ohos-armv7: 4219.1s -> 3941.5s (-6.6%)
  10. x86_64-rust-for-linux: 2898.8s -> 3086.9s (6.5%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (5767910): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -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%] 98
Improvements ✅
(secondary)
-0.6% [-1.2%, -0.1%] 47
All ❌✅ (primary) -0.6% [-1.5%, -0.2%] 98

Max RSS (memory usage)

Results (primary 0.1%)

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

mean range count
Regressions ❌
(primary)
1.1% [1.1%, 1.1%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.9% [-0.9%, -0.9%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.1% [-0.9%, 1.1%] 2

Cycles

Results (primary -5.0%, secondary 2.5%)

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.5% [2.5%, 2.5%] 1
Improvements ✅
(primary)
-5.0% [-5.0%, -5.0%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) -5.0% [-5.0%, -5.0%] 1

Binary size

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

Bootstrap: 473.366s -> 473.657s (0.06%)
Artifact size: 388.38 MiB -> 388.42 MiB (0.01%)

@nnethercote nnethercote deleted the DepNodeColor-tweaks branch October 9, 2025 09:12
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) merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.

6 participants