[DO NOT MERGE] Experiment with micro-optimizing push_str calls

[lolbinarycat]

No description provided.

[lolbinarycat]

@bors2 try @rust-timer queue

[lolbinarycat]

@bors try cancel

[rust-bors]

Try build cancelled. Cancelled workflows:

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

[lolbinarycat]

@bors2 try @rust-timer queue

[lolbinarycat]

@bors try cancel

[rust-bors]

Try build cancelled. Cancelled workflows:

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

[lolbinarycat]

@bors2 try @rust-timer queue

[Kobzol]

Btw, you don't need to cancel the previous try build when making a new one. Bors will automatically cancel the previous one.

[rust-log-analyzer]

The job aarch64-gnu-llvm-20-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[RUSTC-TIMING] rustc_demangle test:false 1.214
error: missing documentation for a method
    --> library/alloc/src/string.rs:1117:5
     |
1117 |     pub fn push_str_slice(&mut self, slice: &[&str]) {
     |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     |
     = note: `-D missing-docs` implied by `-D warnings`
     = help: to override `-D warnings` add `#[allow(missing_docs)]`

[rust-bors]

☀️ Try build successful (CI)
Build commit: 978d49e (978d49ebec63bc482a297308eb28bd9bfff55fb6, parent: c90bcb9571b7aab0d8beaa2ce8a998ffaf079d38)

[lolbinarycat]

Huh. CI failed but the try build didn't, is this another case of a check only being run in CI, or did something about bors change so that perf can continue even if there's an issue?

[rust-timer]

Finished benchmarking commit (978d49e): 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)

Results (primary -2.3%)

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

Cycles

Results (secondary -5.8%)

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

Binary size

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

Bootstrap: 475.185s -> 474.535s (-0.14%)
Artifact size: 390.81 MiB -> 390.80 MiB (-0.00%)

[lolbinarycat]

It's a very slight improvement by every metric, including artifact size, surprisingly. I think I might open an ACP for push_str_slice, it's not a huge improvement, but it's basically free for any code that builds strings in this manner, and I do suspect there's probably some user who is doing this in a hot inner loop and would appreciate saving some cycles (i saw around a 30% improvement in local microbenchmarks vs just calling push_str twice, probably relevant for some serialization code).

[Kobzol]

The default try build just builds the compiler, and doesn't run any tests. So often it succeeds even if CI fails, it's by design.

[Kobzol]

FWIW, the artifact size is noise, and the icount results are a wash. It doesn't seem to me that this has an effect.

[lolbinarycat]

It is a struggle to get microoptimizations to show up as statistically significant, and if you batch them together it's hard to tell if one of them is just making a way bigger difference than the others.

Also, what about the memory improvements?

[paolobarbolini]

Could this benefit the current impl Extend<[thing that derefs to &str]> for String category of implementations by having them call push_str_slice in batches? If that were to work, it wouldn't require adding a new API.

[lolbinarycat]

Now that #149694 has made its way to beta, it would be possible to revive this using String::extend.