Optimize `ToString` implementation for integers by GuillaumeGomez · Pull Request #136264 · rust-lang/rust

GuillaumeGomez · 2025-01-29T21:24:45Z

The benchmark results are:

name	1.87.0-nightly (`3ea711f` 2025-03-09)	With this PR	diff
bench_i16	32.06 ns/iter (+/- 0.12)	17.62 ns/iter (+/- 0.03)	-45%
bench_i32	31.61 ns/iter (+/- 0.04)	15.10 ns/iter (+/- 0.06)	-52%
bench_i64	31.71 ns/iter (+/- 0.07)	15.02 ns/iter (+/- 0.20)	-52%
bench_i8	13.21 ns/iter (+/- 0.14)	14.93 ns/iter (+/- 0.16)	+13%
bench_u16	31.20 ns/iter (+/- 0.06)	16.14 ns/iter (+/- 0.11)	-48%
bench_u32	33.27 ns/iter (+/- 0.05)	16.18 ns/iter (+/- 0.10)	-51%
bench_u64	31.44 ns/iter (+/- 0.06)	16.62 ns/iter (+/- 0.21)	-47%
bench_u8	10.57 ns/iter (+/- 0.30)	13.00 ns/iter (+/- 0.43)	+22%

More information about it in the original comment.

r? @workingjubilee

rustbot · 2025-01-29T21:24:48Z

Could not assign reviewer from: workingjubilee.
User(s) workingjubilee are either the PR author, already assigned, or on vacation. Please use r? to specify someone else to assign.

rustbot · 2025-01-29T21:24:54Z

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
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

GuillaumeGomez · 2025-01-29T22:17:07Z

I'm very confused by the CI errors. Did I unfold a very weird bug somehow? Like 0 != 0. 😮

workingjubilee · 2025-01-30T03:56:08Z

specialization strikes again, perhaps

theemathas · 2025-01-30T04:00:32Z

It seems to me that the tests are testing for a known miscompilation: #107975

theemathas · 2025-01-30T04:08:20Z

I'm guessing that this PR caused the compiler to be able to figure out that calling to_string on a number doesn't cause that number to change, allowing more optimizations to happen, causing the miscompilation to behave differently.

workingjubilee · 2025-01-30T06:04:25Z

lovely.

GuillaumeGomez · 2025-01-30T11:02:20Z

Fixed CI. So now about benching the change: any suggestion @workingjubilee ?

In the meantime:

@bors try @rust-timer queue

…string, r=<try> Optimize `ToString` implementation for integers Part of rust-lang#135543. Follow-up of rust-lang#133247 and rust-lang#128204. Rather than writing pretty bad benchers like I did last time, `@workingjubilee:` do you have a suggestion on how to check the impact on performance for this PR? Thanks in advance! r? `@workingjubilee`

bors · 2025-01-30T11:03:33Z

⌛ Trying commit 83dc76e with merge 97c5b4b...

bors · 2025-01-30T12:54:07Z

☀️ Try build successful - checks-actions
Build commit: 97c5b4b (97c5b4b9bc9a34c7dde8738389ba12cb733cd54e)

rust-timer · 2025-01-30T14:09:49Z

Finished benchmarking commit (97c5b4b): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

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

Max RSS (memory usage)

Results (primary 0.3%, secondary 2.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	3.2%	[3.2%, 3.2%]	1
Regressions ❌ (secondary)	2.1%	[2.1%, 2.1%]	1
Improvements ✅ (primary)	-2.6%	[-2.6%, -2.6%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[-2.6%, 3.2%]	2

Cycles

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

Binary size

Results (primary 0.1%, secondary 0.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.0%, 1.0%]	22
Regressions ❌ (secondary)	0.5%	[0.5%, 0.5%]	3
Improvements ✅ (primary)	-0.1%	[-0.2%, -0.0%]	6
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	3
All ❌✅ (primary)	0.1%	[-0.2%, 1.0%]	28

Bootstrap: 776.287s -> 777.396s (0.14%)
Artifact size: 328.44 MiB -> 328.53 MiB (0.03%)

workingjubilee · 2025-01-30T16:17:45Z

I don't believe the tests should be changed in this way.

GuillaumeGomez · 2025-01-30T16:19:48Z

I'm not sure if we should keep the code and modify it (like I did) or just comment out the parts that are failing. Or maybe you see a third way?

workingjubilee · 2025-01-30T16:40:42Z

The point of these tests is the series of asserts, changing just one line or two that fails undermines the point.

GuillaumeGomez · 2025-01-30T16:43:02Z

The point was testing that calling to_string on them somehow changed the value. The new checks ensure that it doesn't and I commented as such. Not too sure what else to do on them.

workingjubilee · 2025-01-30T16:57:33Z

These are known-bug tests.

They are testing for the existence of a bug.

We did not fix the bug, because there are other ways to reach the compilation quirks in question. They have little to nothing to do with to_string in particular. We changed the code it was testing from under its feet, so the test has to be different code in order to still be a useful test, as what we want is to verify when LLVM stops miscompiling a sequence of LLVMIR.

GuillaumeGomez · 2025-01-30T16:59:21Z

Oh I see. So in short, calling any method on the type should still trigger the original bug iiuc. Let me give it a try. In the meantime, any idea on how to bench this PR?

GuillaumeGomez · 2025-01-30T17:28:15Z

You were right, just calling another method did the trick. Tests are now back to what they were.

workingjubilee · 2025-01-30T19:10:10Z

Thank you. I will think about that a bit.

bors · 2025-02-04T13:02:05Z

☔ The latest upstream changes (presumably #135265) made this pull request unmergeable. Please resolve the merge conflicts.

GuillaumeGomez · 2025-05-15T19:50:15Z

That was fast, let's try again. =D

@bors retry

bors · 2025-05-15T20:20:34Z

⌛ Testing commit 1ef7585 with merge d97326e...

bors · 2025-05-15T23:29:31Z

☀️ Test successful - checks-actions
Approved by: Amanieu
Pushing d97326e to master...

github-actions · 2025-05-15T23:32:09Z

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 c4e05e5 (parent) -> d97326e (this PR)

Test differences

Show 48 test diffs

48 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 d97326eabfc3b2c33abcb08d6bc117aefa697cb7 --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

dist-x86_64-apple: 8656.9s -> 10727.5s (23.9%)
x86_64-apple-1: 7412.5s -> 9100.9s (22.8%)
x86_64-apple-2: 5629.2s -> 4495.9s (-20.1%)
dist-apple-various: 7424.1s -> 8726.9s (17.5%)
dist-arm-linux: 4573.6s -> 5212.5s (14.0%)
dist-x86_64-musl: 7962.1s -> 7228.9s (-9.2%)
dist-aarch64-apple: 5404.2s -> 5829.9s (7.9%)
dist-i686-linux: 6318.1s -> 5898.9s (-6.6%)
aarch64-gnu-debug: 4294.8s -> 4019.9s (-6.4%)
x86_64-gnu-llvm-20-2: 5944.4s -> 6277.3s (5.6%)

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 · 2025-05-16T02:03:18Z

Finished benchmarking commit (d97326e): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

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

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.3%, 1.1%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.2%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[-0.2%, 1.1%]	4

Max RSS (memory usage)

Results (primary -1.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.9%	[2.1%, 3.7%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-4.9%	[-6.9%, -3.0%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-1.0%	[-6.9%, 3.7%]	4

Cycles

Results (primary 1.1%, secondary 3.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

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

Binary size

Results (primary 0.0%, secondary 0.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.1%	[0.0%, 0.2%]	17
Regressions ❌ (secondary)	0.4%	[0.0%, 0.5%]	4
Improvements ✅ (primary)	-0.2%	[-0.6%, -0.0%]	5
Improvements ✅ (secondary)	-0.0%	[-0.1%, -0.0%]	34
All ❌✅ (primary)	0.0%	[-0.6%, 0.2%]	22

Bootstrap: 773.554s -> 773.215s (-0.04%)
Artifact size: 365.48 MiB -> 365.48 MiB (-0.00%)

Kobzol · 2025-05-20T07:02:21Z

Regression on a single benchmark that is new and doesn't have proper noise bounds yet. Also a nice win on the fmt-write-str runtime benchmark, which should be expected here!

@rustbot label: +perf-regression-triaged

…egers, r=tgross35 Use a distinct `ToString` implementation for `u128` and `i128` Part of #135543. Follow-up of #136264. When working on #142098, I realized that `i128` and `u128` could also benefit from a distinct `ToString` implementation so here it. The last commit is just me realizing that I forgot to add the format tests for `usize` and `isize`. Here is the bench comparison: | bench name | last nightly | with this PR | diff | |-|-|-|-| | bench_i128 | 29.25 ns/iter (+/- 0.66) | 17.52 ns/iter (+/- 0.7) | -40.1% | | bench_u128 | 34.06 ns/iter (+/- 0.21) | 16.1 ns/iter (+/- 0.6) | -52.7% | I used this code to test: ```rust #![feature(test)] extern crate test; use test::{Bencher, black_box}; #[inline(always)] fn convert_to_string<T: ToString>(n: T) -> String { n.to_string() } macro_rules! decl_benches { ($($name:ident: $ty:ident,)+) => { $( #[bench] fn $name(c: &mut Bencher) { c.iter(|| convert_to_string(black_box({ let nb: $ty = 20; nb }))); } )+ } } decl_benches! { bench_u128: u128, bench_i128: i128, } ```

…egers, r=tgross35 Use a distinct `ToString` implementation for `u128` and `i128` Part of rust-lang/rust#135543. Follow-up of rust-lang/rust#136264. When working on rust-lang/rust#142098, I realized that `i128` and `u128` could also benefit from a distinct `ToString` implementation so here it. The last commit is just me realizing that I forgot to add the format tests for `usize` and `isize`. Here is the bench comparison: | bench name | last nightly | with this PR | diff | |-|-|-|-| | bench_i128 | 29.25 ns/iter (+/- 0.66) | 17.52 ns/iter (+/- 0.7) | -40.1% | | bench_u128 | 34.06 ns/iter (+/- 0.21) | 16.1 ns/iter (+/- 0.6) | -52.7% | I used this code to test: ```rust #![feature(test)] extern crate test; use test::{Bencher, black_box}; #[inline(always)] fn convert_to_string<T: ToString>(n: T) -> String { n.to_string() } macro_rules! decl_benches { ($($name:ident: $ty:ident,)+) => { $( #[bench] fn $name(c: &mut Bencher) { c.iter(|| convert_to_string(black_box({ let nb: $ty = 20; nb }))); } )+ } } decl_benches! { bench_u128: u128, bench_i128: i128, } ```

…n-128-integers, r=tgross35 Use a distinct `ToString` implementation for `u128` and `i128` Part of rust-lang#135543. Follow-up of rust-lang#136264. When working on rust-lang#142098, I realized that `i128` and `u128` could also benefit from a distinct `ToString` implementation so here it. The last commit is just me realizing that I forgot to add the format tests for `usize` and `isize`. Here is the bench comparison: | bench name | last nightly | with this PR | diff | |-|-|-|-| | bench_i128 | 29.25 ns/iter (+/- 0.66) | 17.52 ns/iter (+/- 0.7) | -40.1% | | bench_u128 | 34.06 ns/iter (+/- 0.21) | 16.1 ns/iter (+/- 0.6) | -52.7% | I used this code to test: ```rust #![feature(test)] extern crate test; use test::{Bencher, black_box}; #[inline(always)] fn convert_to_string<T: ToString>(n: T) -> String { n.to_string() } macro_rules! decl_benches { ($($name:ident: $ty:ident,)+) => { $( #[bench] fn $name(c: &mut Bencher) { c.iter(|| convert_to_string(black_box({ let nb: $ty = 20; nb }))); } )+ } } decl_benches! { bench_u128: u128, bench_i128: i128, } ```

…Amanieu Implement `int_format_into` feature I took over rust-lang#138338 with `@madhav-madhusoodanan's` approval. Since rust-lang#136264, a lot of changes happened so I made use of them to reduce the number of changes. ACP approval: rust-lang/libs-team#546 (comment) ## Associated Issue - rust-lang#138215 r? `@hanna-kruppe`

Rollup merge of #142098 - GuillaumeGomez:int_format_into, r=Amanieu Implement `int_format_into` feature I took over #138338 with `@madhav-madhusoodanan's` approval. Since #136264, a lot of changes happened so I made use of them to reduce the number of changes. ACP approval: rust-lang/libs-team#546 (comment) ## Associated Issue - #138215 r? `@hanna-kruppe`

…Amanieu Implement `int_format_into` feature I took over rust-lang#138338 with `@madhav-madhusoodanan's` approval. Since rust-lang#136264, a lot of changes happened so I made use of them to reduce the number of changes. ACP approval: rust-lang/libs-team#546 (comment) ## Associated Issue - rust-lang#138215 r? `@hanna-kruppe`

rustbot assigned Mark-Simulacrum Jan 29, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jan 29, 2025

This comment has been minimized.
Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jan 30, 2025

This comment has been minimized.
Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jan 30, 2025

GuillaumeGomez force-pushed the optimize-integers-to-string branch from 83dc76e to 1713773Compare January 30, 2025 17:27

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 May 15, 2025

bors added the merged-by-bors This PR was explicitly merged by bors. label May 15, 2025

bors merged commit d97326e into rust-lang:masterMay 15, 2025

rustbot added this to the 1.89.0 milestone May 15, 2025

bors mentioned this pull request May 16, 2025
Functionality for int_format_into for integer types #138338
Closed

rustbot added the perf-regression Performance regression. label May 16, 2025

GuillaumeGomez deleted the optimize-integers-to-string branch May 16, 2025 08:05

rustbot added the perf-regression-triaged The performance regression has been triaged. label May 20, 2025

This was referenced Jun 5, 2025
Implement int_format_into feature #142098
Merged
Use a distinct ToString implementation for u128 and i128#142294
Merged

jhpratt mentioned this pull request Sep 3, 2025
Update benchmark dtolnay/itoa#59
Closed

Uh oh!

Uh oh!

Conversation

GuillaumeGomez commented Jan 29, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Jan 29, 2025

Uh oh!

rustbot commented Jan 29, 2025

Uh oh!

This comment has been minimized.

GuillaumeGomez commented Jan 29, 2025

Uh oh!

workingjubilee commented Jan 30, 2025

Uh oh!

theemathas commented Jan 30, 2025

Uh oh!

theemathas commented Jan 30, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

workingjubilee commented Jan 30, 2025

Uh oh!

GuillaumeGomez commented Jan 30, 2025

Uh oh!

This comment has been minimized.

bors commented Jan 30, 2025

Uh oh!

bors commented Jan 30, 2025

Uh oh!

This comment has been minimized.

rust-timer commented Jan 30, 2025

Overall result: ✅ improvements - no action needed

Uh oh!

workingjubilee commented Jan 30, 2025

Uh oh!

GuillaumeGomez commented Jan 30, 2025

Uh oh!

workingjubilee commented Jan 30, 2025

Uh oh!

GuillaumeGomez commented Jan 30, 2025

Uh oh!

workingjubilee commented Jan 30, 2025

Uh oh!

GuillaumeGomez commented Jan 30, 2025

Uh oh!

GuillaumeGomez commented Jan 30, 2025

Uh oh!

workingjubilee commented Jan 30, 2025

Uh oh!

bors commented Feb 4, 2025

Uh oh!

GuillaumeGomez commented May 15, 2025

Uh oh!

bors commented May 15, 2025

Uh oh!

bors commented May 15, 2025

Uh oh!

github-actionsBot commented May 15, 2025

Test differences

Job duration changes

Uh oh!

rust-timer commented May 16, 2025

Overall result: ❌✅ regressions and improvements - please read the text below

Uh oh!

Kobzol commented May 20, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

14 participants

GuillaumeGomez commented Jan 29, 2025•
edited
Loading

theemathas commented Jan 30, 2025•
edited
Loading