Use log10 for optimizations

[wooster0]

I think the new integer log10 introduced in #70887 has some great potential to be used for some optimization (and the already existing {f32, f64}::log10 too) regarding integer length counting.

If this is benchmarked and doesn't really result in improvements or even results in regressions, I'd leave this open and wait for #88788 to be merged and then try again, but judging by my own testing, there seem to be some improvements already: https://rust.godbolt.org/z/EexoddGhe

• Refactor the formatting with buffer thing
• Optimize impl ToString for u8 and impl ToString for i8 with an extra benchmark run after the other stuff is done
• I was also thinking about whether it makes sense to add something like count_digits that contains this functionality, and I think it does make sense. Maybe I should open an issue for that? (See https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Adding.20a.20new.20function.20to.20std)
• Figure out what to put in since = "..."
• When Use log10 for optimizations #89737 (comment) is resolved, have a more sophisticated float length prediction (or add a FIXME).
• Note to self: don't forget your private todo list.
• Add FIXMEs to later change some log10s to things like (-i16::MAX).to_string().len().

For now this is just a draft to see if this does anything.

[rust-highfive]

r? @joshtriplett

(rust-highfive has picked a reviewer for you, use r? to override)

[wooster0]

@bors try @rust-timer queue
r? @ghost

[rust-timer]

Insufficient permissions to issue commands to rust-timer.

[bors]

@r00ster91: 🔑 Insufficient privileges: not in try users

[wooster0]

May I have a benchmark run on this? Specifically for this to_string: https://github.com/rust-lang/rust/pull/89737/files#diff-1a13885e89de65916e7e0f9436a79cb2e697e23dcaa1a24e8fb3106d8b89dc7eR2404

[wooster0]

5: @has check failed
 `XPATH PATTERN` did not match
 // @has foo/primitive.i32.html '//div[@id="impl-ToString"]//h3[@class="code-header in-band"]' 'impl<T> ToString for T'

Same error. As I suspected, the changes done in src/librustdoc/html/sources.rs here are indeed unrelated and it's something else. I'm pretty sure the alloc tests ran and succeeded before this so it's probably not the new to_string implementations for integers either.
It says 'impl<T> ToString for T' in that check which looks very suspicious to me. I think it does some checks that fail when my implementations are there (even though the implementations themselves are correct I think). Does anyone that works on librustdoc have a clue what that failing test could stand for?

[fee1-dead]

@bors try @rust-timer queue

The floating point ToString implementation is not optimized, but we can see if integers benefit from this optimization. Tests do not need to pass for a benchmark run.

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 9df17ffb5c33eb34ffca5b225027c167cdf80ccf with merge ad3bd17c19765c771c75e437c77cc66e4a476095...

[bors]

☀️ Try build successful - checks-actions
Build commit: ad3bd17c19765c771c75e437c77cc66e4a476095 (ad3bd17c19765c771c75e437c77cc66e4a476095)

[rust-timer]

Queued ad3bd17c19765c771c75e437c77cc66e4a476095 with parent 0c87288, future comparison URL.

[rust-timer]

Finished benchmarking commit (ad3bd17c19765c771c75e437c77cc66e4a476095): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

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 led to changes in compiler perf.

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

[jyn514]

Does anyone that works on librustdoc have a clue what that failing test could stand for?

Feel free to ping me or another team member in the future - I wouldn't have seen this unless I was idly glancing through PRs.

[jyn514]

@r00ster91 I suspect the new impl-ToString header no longer exists and it's called ToString-1 isntead? I can't find the old ToString implementation for i32, though, I'm not sure why the test passed before.

[wooster0]

@jyn514

Feel free to ping me or another team member in the future - I wouldn't have seen this unless I was idly glancing through PRs.

Ah, ok, sure!

@r00ster91 I suspect the new impl-ToString header no longer exists and it's called ToString-1 isntead? I can't find the old ToString implementation for i32, though, I'm not sure why the test passed before.

Oh, okay. Maybe that's it. I will try ToString-1 then (did that in e8ddaeb).
Maybe the test passed before because of some weird test caching issue? But I'm like 99% sure there is no such "test cache".
I'm not sure either...

[wooster0]

Doesn't look like that fixed it. The additional changes I made in src/test/rustdoc/generic-impl.rs (because I thought it has the same issue) seems to have only made it worse.

[bors]

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

[camelid]

Why did this change? This seems like a bug in this PR.

[wooster0]

See #89737 (comment) and #89737 (comment)

I will resolve the conflicts now and see if it's fixed. I will just remove changes to this file altogether because yeah I shouldn't have to change anything there.

[wooster0]

Removed the specializations and stuff, those things were probably not worth it anyway.

[bors]

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

[Dylan-DPC]

@r00ster91 if you can resolve the conflicts we can get this reviewed quickly after that

[wooster0]

@rustbot ready

[camelid]

r? rust-lang/libs

[camelid]

I'll let T-libs review this.

[bors]

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

[dtolnay]

I am a bit lost in the long comment history above. It seems like people thought this should be faster, but it turned out to be slower when measured, and after a few rounds of code changes there has been no new benchmarking presented after the most recent code change (in which "specializations and stuff" was removed).

What benchmark is the most recent revision of the PR based on?

If it isn't something already checked into the repo, would it be possible to get that benchmark added to either library/core/benches/num or library/core/benches/fmt?

[wooster0]

It is probably best to just close this because the remaining changes are just macro formatting (which I expect to be automated at some point anyway) and very minor changes that turn / 10 loops into less readable log10s. Maybe LLVM already turns those into some kind of log10s already anyway. I think the point of this PR has been lost so I'll close this but if you believe the macro formatting changes are worth doing right now, you can tell me and I'll make another PR.

[dtolnay]

I would be happy to accept your macro formatting changes in a new PR.