This type of thing reminds me of the three articles ending in https://fitzgeraldnick.com/2018/02/26/speed-without-wizardry... (which has links to the first two parts of the saga), where one guy rewrote stuff in Rust for performance, another demonstrated how it was possible to make the JavaScript version faster than the Rust by some algorithm changes and by various painful and fragile tricks requiring detailed knowledge of the runtime environment, and finally the first guy applied the applicable parts of that back to the Rust, after which it handily beat the JavaScript again while also being more consistent and dependable.
I think most people are moderately-optimized benchmarks, i.e. moderate effort expended relative to baseline implementation effort.
That is, people are interested in getting the most performance out of the least amount of effort.
Obviously some people want and need to care about extreme peak optimization. But if you are writing benchmarks for a wide audience, that probably should not be your priority.
I'm sure if you submitted a better implementation he'd be happy to add it in.
Rust uses UTF-8 internally for Strings, so it's very efficient to parse a file into a String, then using slices to go through it... this is probably the best you can get as parsing ASCII input as UTF-8 is very efficient (the 0-bit is always zero in ASCII, the unicode decoder only needs to check that's the case for every byte, so it's not some kind of complicated computation it's doing to decode)...
If you use bytes for everything, you will make the whole code much harder to follow and it still won't run faster.
Check for yourself: https://github.com/renatoathaydes/prechelt-phone-number-enco...
Your suggestions would make the code much slower.
There may be ways to make it a bit faster, but not with your silly suggestions.
