Faster parsing for lower numbers for radix up to 16

[gilescope]

While musing on #83088 I noticed that we could use str len to establish if the input was guarenteed not to overflow the containing type.

From what I can see this is conservative enough (i64 having the least wiggle room) that we can safely skip the overflow checks because we have ruled out overflow and that seems to improve performance by 1/4 to 1/3 for numbers in the range. Given that most numbers are statistically on the small side rather than near the type limits, I'm tempted by this. As it stands it doesn't really help i8 much as it's so small a range of numbers, but it does work well with u8 ( FF ) which is far more common.

I don't like adding unsafety, but this might be worth it.

[rust-highfive]

r? @kennytm

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

[crlf0710]

@gilescope Ping from triage! CI is still red here. Mind fixing that?

[pickfire]

I believe the other pull request superseeds this pull request. Which @gilescope is still experimenting with.

[gilescope]

@pickfire while I'd like to find a way to improve base10 parsing specifically, this is a simple speedup for all radix with little down side. It focuses on small numbers which are in general more common so it's likely to kick in most of the time.

I think given the simplicity we should move forward with this PR.

[pickfire]

small numbers

You may also want to write down how small there.

[LingMan]

Two more nits and you might want to squash down your commits a bit but otherwise LGTM.

[gilescope]

Hmm, redoing the perf testing pulling out let unchecked_additive_op = to prevent the duplication does lead to a perormance penalty. :-(

[crlf0710]

@gilescope Ping from triage, what's next steps here?

[crlf0710]

@gilescope Ping from triage, any updates here?

[JohnCSimon]

@gilescope Ping from triage. Can you please post the status of this MR?

[LingMan]

@gilescope Does replacing the contents of the unsafe block with this, resolve the performance issue you saw?

macro_rules! run_loop {($unchecked_additive_op:ident) => {for&c in digits {
result = result.unchecked_mul(radix);let x = (c aschar).to_digit(radix).ok_or(PIE{ kind:InvalidDigit})?;
result = T::$unchecked_additive_op(&result, x);}}}if is_positive {run_loop!(unchecked_add)}else{run_loop!(unchecked_sub)};

[JohnCSimon]

@gilescope
Ping from triage: I'm closing this one due to not being touched since june , please feel to reopen when you are ready to continue with this.

@rustbot label: +S-inactive

[gilescope]

@JohnCSimon can we reopen this PR. I didn't see LingMan's comment. I think this is good now with LingMan's change. Is it possible to kick off a perf run? (I've rebased to bring this up to date with master)

[gilescope]

(Sorry I've been away a long time.)

[kennytm]

the branch was force-pushed or recreated so the PR can't be re-opened. you could submit a new PR.