Optimise `atoi()` implementation

[pulsar pendant]

going the bytes route is definitely better

I'm not sure I agree with the unrolling of every case, but it might be faster - needs testing

there are ways to make it faster, but the question is how arcane do you want to go

this exists for instance https://lemire.me/blog/2023/09/22/parsing-integers-quickly-with-avx-512/

but it's not something I'd expect basically anyone to do

[hallow gust]

why do you check exact equality for each ASCII byte pattern instead of using ASCII as designed and and doing asciiDigit(x: u8) -> u8 {x - b'0'} as the ASCII digits are laid out contiguously
https://www.ascii-code.com/
The cost of branching might be significant here, though of course this can become a jump-table but could be directly branchless. It's also annoying to write?
The design of ASCII has several considerations for more convenient/performant processing

As you only read the input your function declaration could take an &str as fn my_atoi(s: &str) -> i32 which would support more import types without forcing a copy of string slices to pass an owned String

[hallow gust]

I've been able to change the signature with regards to mutability and compatible types in C++ for leetcode

[jovial crag]

You might be able to shave some millis off the impl then by doing String::leak, lol

that will get rid of the memory freeing of the String, obviously bad in production but for silly things like leetcode it's fun

[pulsar pendant]

does leetcode do any benchmarking against C?

if they do, forcing you to use string is unfair

[hallow wadi]

https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/