base_n: speedup push_str

[klensy]

This speedup base_n::push_str by removing few range bounds and utf8 check.

Unsafe is ugly here, but better version is welcome.

[rust-highfive]

r? @davidtwco

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

[davidtwco]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 168111d8134207b4c72284f0ca4954eac1a6040d with merge dce87a54a1682189e15b6dfb02c488edfd7223ff...

[bors]

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

[rust-timer]

Queued dce87a54a1682189e15b6dfb02c488edfd7223ff with parent 2336406, future comparison URL.

[rust-timer]

Finished benchmarking try commit (dce87a54a1682189e15b6dfb02c488edfd7223ff): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

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

[klensy]

No perf change, but at least manual bench run faster.

[davidtwco]

I don't think this is worth landing if it doesn't have a measurable effect on perf. If there's a specific case that this improves, or you have further ideas that you'd like to try, then we can re-open this.

No perf change, but at least manual bench run faster.

Do you mean manual benchmarking of this function in isolation, or a test case that rustc is noticably faster at compiling with these changes applied?

[klensy]

@davidtwco Faster in synthetic tests, plus it maybe help with #85530, as it used in mangling v0.

[davidtwco]

Could you add a commit to this MR that enables the new symbol mangling? We'll drop it after, but we can use it to run perf with the new mangling on and see how this impacts the performance of that.

[JohnCSimon]

Ping from triage:
@klensy - can you please address the comment from davidtwco?

[michaelwoerister]

This probably doesn't need to be unsafe. LLVM will eliminate the bounds check because the assertion above already allows it to proof the condition given in the comment.

[crlf0710]

@klensy Ping from triage! Any updates on this?

[JohnCSimon]

Triage:
@klensy
I'm closing this as inactive as it hasn't seen any movement since June.
Please feel free to open if you're going to continue. Thanks!