See if we can find a way to mutate BigInts for float parsing performance

[quinnj]

No description provided.

[quinnj]

@simonbyrne, I'd like to pick your brain on this at some point, in case you have any ideas on how to avoid the extra allocations from our usage of BigInts.

[simonbyrne]

Tough to say. The problem with BigInts is that they will compute all the way to the last digit, which may well be overkill.

It might be worth trying to do it via BigFloats, since that is sort of what they're designed for.

[simonbyrne]

To expand on what I was thinking: have an array of BigFloat powers of 10, stored so as to be exact, then use the in-place MPFR operations, with the output BigFloat having desired precision (i.e. 53 for Float64), then convert that to the output value. I've been doing some work to make it easier to specify precisions, but we should also expose an in-place interface so people don't have to keep writing ccalls.

The main downside is that BigFloat doesn't have Int128 conversion functions, or mpfr_z_div (for dividing a BigInt by a BigFloat).

[simonbyrne]

Another option is to do some double-double tricks, then only fall back on the slow path in particularly bad cases.

[nalimilan]

In which cases do we need more than double-double precision?

[simonbyrne]

Some examples in http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.144.5889&rep=rep1&type=pdf

e.g.

julia> a = big"231010996856685e-73"
2.310109968566849999999999999999999999999999999999999999999999999999999999999993e-59

julia> f = Float64(a)
2.31010996856685e-59

julia> (a-f)/eps(f)
4.999999999999999944411148283894126856425861653096805477178550232687750593198741e-01