Change:
} } <ins> #[stable(feature = "u8_to_string_specialization", since = "1.999.0")] impl ToString for u8 { #[inline] fn to_string(&self) -> String { let mut buf = String::with_capacity(3); let mut n = *self; if n >= 10 { if n >= 100 { buf.push((b'0' + n / 100) as char); n %= 100; } buf.push((b'0' + n / 10) as char); n %= 10; } buf.push((b'0' + n) as char); buf } } #[stable(feature = "i8_to_string_specialization", since = "1.999.0")] impl ToString for i8 { #[inline] fn to_string(&self) -> String { let mut buf = String::with_capacity(4); if self.is_negative() { buf.push('-'); } let mut n = self.unsigned_abs(); if n >= 10 { if n >= 100 { buf.push('1'); n -= 100; } buf.push((b'0' + n / 10) as char); n %= 10; } buf.push((b'0' + n) as char); buf } } </ins> #[stable(feature = "str_to_string_specialization", since = "1.9.0")] impl ToString for str { #[inline]

Discussion:
Based on Not sure if we can do much about integer to string but I bet we can do something for byte to string. (note that char benchmark is not updated with the latest specialization update by
Bench code of Ivan:
Oh, looks like we don't know if the is a valid utf-8 string or not, byte is probably invalid. I wonder if one can have a specialized for and others numbers. Looking at which most likely uses, I don't think we need for but not sure if using a different value for different type will speed it up. I also don't think we can parse 4 characters at a time for or . Same, not sure if separating them is good.
I have a rough plan but it isn't quite clear. One of these things is porting the similar functions in C++ to make it more efficient: See:
Maybe we could also try porting the go version in , and then see which one is the fastest implementation.
I have sort of a patch but I don't know how long the benchmark will run with , I wish there is a way to benchmark certain functions, still it took too long. I wrote a patch to use different stack size to parse different type of integer, not sure if this will improve parsing performance. <details<summaryPatch</summary</details How do I know if it is faster quickly?
I may build stage1 rustc and run your benchmark. Also comparing with result of master rustc.
How do you do that? I use but it takes so long even when I run that on a shared compile farm with 16 cores.
The hard code number is not bad but I would go with creating a trait similar to for a integer.
I do and use to create a custom toolchain. Then I use that toolchain to bench custom benchmark (not libcore). : with or .
But rust does not have numeric limits right? So I need to add something like and but keep it only for internal use?
Yeah, my plan is to add that trait to Rust. But you are free to hardcode that number to macro unless lib/compiler team push back.
?
My mistake
Btw, why did you want to run bench on ?
I am thinking of trying out the benchmark first and then tweak it, later only add it as a trait, but I don't know if trait can carry value.

But still, making all of what you say when it isn't faster isn't very useful for me. Because I want to test out if for did improve, which should also improves the speed of . I saw that there might have some benchmarks on it there. EDIT: By the way, it's .
It is a brick of the procedure. You might interest in reading the in C++.
Thanks, that's very helpful. I was looking for that here and there but I cannot find it.
But how should I proceed with this? The method you specified does not seemed to work for libcore with a bunch of errors. My idea is work it out into two parts, first identify if this speeds up integer to string conversion, second work out the numeric limits you mentioned. But I don't know if it is faster, but still I will try running benchmark here, but it will probably take a long time.
You shouldn't have to. That is my very long term/rough plan and I may have to write an RFC/demo to convince the compiler team. Probably writing a micro benchmark to compare C++ and Rust . Honestly I don't know, that is in my own hope.
I tried running a benchmark and here are the results. Summary of But still, I don't know why the results differs a lot, maybe because it's a compile farm.