Use DenseBit for drop_live_at in liveness tracing

[Kobzol]

View all comments

I noticed that drop_live_at only ever gets point, and never range, inserts, so I switched it over to DenseBitSet. This provides some nice wins on serde.

However, the add_drop_live_facts_for function expects to receive an IntervalSet. I first tried to switch the type of LiveRegions::AtPoints from SparseIntervalMatrix to SparseBitMatrix, but that had regressions.

So in this PR, I simply reconstruct an IntervalSet from a DenseBitSet. Not super pretty, but perf. looks reasonable.

Let me know if this makes sense or not! :)

r? jackh726

[jackh726]

Cool :) r=me with comment added

[jackh726]

@bors rollup=never

[Kobzol]

Cool, added a comment. Thank you!

@bors r=jackh726

And for good measure:
@bors try @rust-timer queue

[rust-bors]

📌 Commit 855183d has been approved by jackh726

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 5. This pull request will be tested once the tree is reopened.

Reason for tree closure: spurious failures

[rust-bors]

⚠️ A new commit 1b1b92ed33d64bc3d722be6f13f9fc6a23faa858 was pushed.

This pull request was unapproved.

[Kobzol]

Impressive, I managed to make the code stop compiling by adding a comment 🤦 Enough GitHub for today. Second try:

@bors r=jackh726
@bors try

[rust-bors]

📌 Commit 1b1b92e has been approved by jackh726

It is now in the queue for this repository.

🌲 The tree is currently closed for pull requests below priority 5. This pull request will be tested once the tree is reopened.

Reason for tree closure: spurious failures

[rust-bors]

☀️ Try build successful (CI)
Build commit: 57ac888 (57ac8880a9ace2c2311fd96b2b77f5fad68483b4)
Base parent: 745de6e (745de6eca673de5329ec68f2689629a5ca45ab35)

[rust-timer]

Finished benchmarking commit (57ac888): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never rustc-perf
@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.2%	[0.2%, 0.3%]	2
Regressions ❌ (secondary)	0.3%	[0.1%, 0.4%]	10
Improvements ✅ (primary)	-1.7%	[-2.2%, -1.4%]	12
Improvements ✅ (secondary)	-1.7%	[-2.1%, -1.4%]	9
All ❌✅ (primary)	-1.4%	[-2.2%, 0.3%]	14

Max RSS (memory usage)

Results (primary 0.4%)

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

	mean	range	count
Regressions ❌ (primary)	0.6%	[0.4%, 0.8%]	5
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.6%	[-0.6%, -0.6%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.4%	[-0.6%, 0.8%]	6

Cycles

Results (primary -0.6%, secondary -1.2%)

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

	mean	range	count
Regressions ❌ (primary)	0.6%	[0.5%, 0.8%]	5
Regressions ❌ (secondary)	2.9%	[2.9%, 2.9%]	1
Improvements ✅ (primary)	-0.9%	[-2.3%, -0.4%]	17
Improvements ✅ (secondary)	-3.3%	[-3.3%, -3.3%]	2
All ❌✅ (primary)	-0.6%	[-2.3%, 0.8%]	22

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 478.441s -> 476.44s (-0.42%)
Artifact size: 403.53 MiB -> 403.61 MiB (0.02%)

[rust-bors]

☀️ Test successful - CI
Approved by: jackh726
Duration: 3h 20m 34s
Pushing 1edd55d to main...

[github-actions]

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 0d31508 (parent) -> 1edd55d (this PR)

Test differences

Show 3 test diffs

3 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 1edd55dcfcd573872c727fa3e086369a71661ee0 --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. test-x86_64-msvc-2: 1h 43m -> 2h 39m (+53.6%)
2. test-x86_64-mingw-1: 2h 8m -> 3h 12m (+50.1%)
3. test-x86_64-gnu-llvm-21-1: 42m 45s -> 1h 1m (+43.5%)
4. dist-x86_64-llvm-mingw: 2h 19m -> 1h 20m (-42.6%)
5. test-x86_64-msvc-ext2: 1h 42m -> 1h 3m (-37.6%)
6. test-arm-android: 1h 18m -> 1h 48m (+37.4%)
7. dist-arm-linux-gnueabi: 1h 31m -> 1h 3m (-30.8%)
8. test-pr-check-2: 45m 8s -> 32m 34s (-27.8%)
9. test-x86_64-msvc-ext3: 1h 27m -> 1h 51m (+27.6%)
10. dist-s390x-linux: 1h 14m -> 1h 33m (+25.9%)

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]

Finished benchmarking commit (1edd55d): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

• If the regression was expected or you think it can be justified,
  please write a comment with sufficient written justification, and add
  @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
• If you think that you know of a way to resolve the regression, try to create
  a new PR with a fix for the regression.
• If you do not understand the regression or you think that it is just noise,
  you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
  were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

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.2%	[0.2%, 0.3%]	2
Regressions ❌ (secondary)	0.2%	[0.1%, 0.3%]	5
Improvements ✅ (primary)	-1.7%	[-2.1%, -1.3%]	12
Improvements ✅ (secondary)	-0.9%	[-1.9%, -0.1%]	6
All ❌✅ (primary)	-1.4%	[-2.1%, 0.3%]	14

Max RSS (memory usage)

Results (primary 0.1%, secondary 1.6%)

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

	mean	range	count
Regressions ❌ (primary)	1.1%	[0.5%, 1.7%]	2
Regressions ❌ (secondary)	3.0%	[2.0%, 3.8%]	6
Improvements ✅ (primary)	-1.0%	[-1.5%, -0.5%]	2
Improvements ✅ (secondary)	-2.6%	[-4.2%, -1.1%]	2
All ❌✅ (primary)	0.1%	[-1.5%, 1.7%]	4

Cycles

Results (primary 0.7%, secondary 0.5%)

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

	mean	range	count
Regressions ❌ (primary)	1.2%	[0.5%, 2.7%]	14
Regressions ❌ (secondary)	4.3%	[2.2%, 7.4%]	5
Improvements ✅ (primary)	-0.8%	[-1.2%, -0.5%]	4
Improvements ✅ (secondary)	-4.1%	[-4.4%, -3.7%]	4
All ❌✅ (primary)	0.7%	[-1.2%, 2.7%]	18

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 480.949s -> 481.679s (0.15%)
Artifact size: 403.34 MiB -> 403.98 MiB (0.16%)

[Kobzol]

Nice win on serde, and only a tiny regression on cranelift-codegen.

@rustbot label: +perf-regression-triaged