@bors try @rust-timer queue

Oops, forgot we can do more focused perf runs now, hopefully this overwrites the perf run and doesn't start a second one.

@rust-timer queue profiles=doc

@bors try cancel

Try build cancelled. Cancelled workflows:

• https://github.com/rust-lang/rust/actions/runs/21924761758

@bors try

☀️ Try build successful (CI)
Build commit: 08f322c (08f322c258c616d236bf389f7abf02202a524729, parent: 7057231bd78d6c7893f905ea1832365d4c5efe17)

Finished benchmarking commit (08f322c): comparison URL.

Overall result: no relevant changes - 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

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

Max RSS (memory usage)

Cycles

Binary size

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

Bootstrap: 476.438s -> 474.386s (-0.43%)
Artifact size: 397.88 MiB -> 397.89 MiB (0.00%)

Like many other micro-optimizations, it doesn't have enough of an impact to actually clear the significance threshold, but it does seem like it helps a bit, and it makes logical sense that it would...

r? @fmease

rustbot has assigned @fmease.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

r? @GuillaumeGomez

What do you think? Are the small (hard to measure) improvements worth it?

I'd tend to say that if code isn't much better and perf doesn't change expected improvement, it's not worth it. In particular, we now add lot more pre-computed lengths that might be hard to keep up to date.