DoubleToStringConverter::ToPrecision has poor (worse than sprintf) performance for a large set of numbers

[troelstm]

The problem lies in DigitGenCounted (in fast-dtoa.cc):
If the fraction is 0 after the first iteration generating the integrals, then the second iteration will be skipped, and less than the requested number of digits (will typically) have been generated, resulting in the method return false, which then leads to a fallback to bignum based conversion.

It's trivial to add a check for the fraction being exactly zero after the first iteration, and then padding with 0 up to the requested number of digits.

What I however can't (yet) answer with 100% certainty is whether this could generate wrong results for some input? (I don't really think so).

The performance issue is seen e.g. for any number in form N*10^M

[floitsch]

I would need to check more, but I believe that the check is necessary, because the function has to assume that the input w is rounded and has an error of 1 ulp.
I'm guessing that there are cases where the created w is within the "correct" range and thus doesn't have any rounding error. However, there is currently no way to figure this out inside the DigitGenCounted function.
It might be interesting to check whether the incoming number fits into a 64bit integer, though. At that point a simple integer "printing" would be faster and simpler (and would never fall back to the big-int solution).

I'm currently very busy, and don't expect to find the time to implement this myself. I could, however, give pointers on where to change the library.