speedup factors of the proposed re-implementation of Double.toString(double)

[raffaello.giulietti at gmail.com]

Hi,

in order to elicit some concrete interest in the proposed
re-implementation of Double.toString(double) [1] to overcome the known
issues [2], I prepared a jar in [3] that runs some benchmarks comparing
the execution times.

It can be executed directly as:
    java --module-path todecbench.jar -m todec

The source code has already been delivered in [4].

The proposed implementation corrects all the known anomalies and the
benchmarks show that it is faster.

While I have no opportunities to run the benchmarks on idle server class
hardware, the speedup factors obtained on my not so recent laptop
(i7-3630QM @ 2.4 GHz, 12 GiB RAM, Windows 10 Pro 64 bit, Oracle java
9.0.4 64 bit) are:

* 11x for non NaN values uniformly distributed over the whole range of
doubles
* 2x for doubles of the form (int)/1e3 ("milli") and (int)/1e6 ("micro")
* on par with doubles of the form (int)

Not shown in the benchmark, but collected over extensive testing, are
speedup factors in-between.

In about 99.4% of the cases no objects are ever allocated (except for
the final result), which helps reducing gc costs. For details about the
algorithmic part see the pdf in [3].

Hope this helps in getting some of you to try the code and give feedback.



Greetings
Raffaello


[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/052355.html
[2] https://bugs.openjdk.java.net/browse/JDK-4511638
[3]
https://drive.google.com/drive/folders/1MErGSOaqDFw2q9rz48WlpBDKyZkLuUqj?usp=sharing
[4]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052696.html