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
