[EXPERIMENT] Check if isolating Matrix::unspecialize dodges regressions - #161632
[EXPERIMENT] Check if isolating Matrix::unspecialize dodges regressions#161632Zalathar wants to merge 1 commit into
Matrix::unspecialize dodges regressions#161632Conversation
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
[EXPERIMENT] Check if isolating `Matrix::unspecializes` dodges regressions
Matrix::unspecializes dodges regressionsMatrix::unspecialize dodges regressions
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (ee3df1b): comparison URL. Overall result: ❌ regressions - 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 @bors rollup=never rustc-perf Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)This perf run didn't have relevant results for this metric. CyclesResults (primary 2.4%, secondary 0.9%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary -0.1%, secondary -0.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 469.882s -> 469.633s (-0.05%) |
|
Unfortunately, it's hard to say whether this result means that |
We know from #161496 that
DenseBitSet::insertis extremely sensitive to seemingly-irrelevant changes.This is a perf experiment to see whether isolating
Matrix::unspecializefrom those changes avoids the regression.