Can the standard library benefit from this?

[hanna-kruppe]

It is my understanding that the main motivation for this library is avoiding the overhead of the std::fmt infrastructure, but I noticed that unlike itoa this isn't the implementation from libcore but an independent one. It's the same basic algorithm (Grisu) but perhaps the separate lineage of the code means there are some optimizations in this implementation that the libcore implementation would also benefit from?

[dtolnay]

There are some differences that would make it a big breaking change for libcore to switch to this implementation. This library formats 1.01e5 as 101000.0 while libcore currently formats it as 101000. This library formats 1.01e101 as 1.01e101 while libcore currently formats it as 10100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000. I don't think the performance would be worth breaking people's existing expectations about the representation.

For itoa I filed dtolnay/itoa#1 to fix the implementation in libcore because that one is a pure performance improvement with no other user-facing differences.

[hanna-kruppe]

Oh, so the speedup is mostly because fewer characters need to be written? That is something that can be fixed to some degree. You're right that the format of float.to_string() can't just change — this was attempted before and rejected, because it actually broke code relying on things like "float strings don't contain e". However, there have been proposals to change this or that part of the format, possibly behind non-default format strings (e.g. {:#} instead of {}): rust-lang/rust#30967 rust-lang/rust#29472 and perhaps more.

I think an RFC that defines alternative, shorter formats would result in a lot of bikeshedding but ultimately be accepted. Maybe in a few weeks I'll get around to writing such an RFC.

[dtolnay]

Oh, so the speedup is mostly because fewer characters need to be written?

Yes and no. The most dramatic speedups are because of that, but even numbers that print out exactly the same are faster by a factor of 2. This is because we avoid the overhead of the std::fmt infrastructure as you said initially.

I would support having this algorithm behind a non-default format string in the standard library.