On May 16 2013, at 20:52 , Alan Eliasen wrote: > On 05/15/2013 07:17 PM, Mike Duigou wrote: >> Hello all; >> >> This issue was originally part of JDK-8006627 (improve performance of >> UUID parsing/formatting) but was split out because it could be split >> out. I've been working incrementally on pieces of 8006627 as my time >> permits. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8007398/1/webrev/ >> >> Since the last rev I have made a separate implementation >> Integer.formatUnsignedInteger for use by Integer rather than sharing >> the Long implementation because it's about 30% faster. I suspect the >> benefits would be even greater on a 32-bit VM or 32-bit native >> platform. > > Mike, > > Do your changes affect performance for all radices, or for certain > radices as implied in some issue titles?
Only the power of two radicies are improved. > It might be beneficial to coordinate with Brian Burkhalter who is > working on integrating my patches to make BigInteger.toString() much > faster. As you know, BigInteger.toString() partially uses > Long.toString(). I think that BigInteger.toString can be improved a lot. In particular, the key to the optimization in Integer/Long.toString at these radicies was the ability to pre-calculate the size of the required character array. For power of 2 radicies I believe BigInteger could perform best by having it's own implementation. > Improving the performance of Long.toString() will > improve the performance of BigInteger, which is great. However, there > is an empirically-found threshold in BigInteger that might benefit from > re-tuning if Long.toString becomes significantly faster, though. The > threshold is intentionally chosen to be a bit conservative for cases > like this, so re-tuning may not have a huge effect. > > I don't use different thresholds based on the radix, but that's > something to consider in the future if it could improve performance. > Radices that are powers of 2 shouldn't need the recursive improvements > in BigInteger.toString. > > If you let me know if these changes get checked in, I can see if > re-tuning the threshold for BigInteger.toString() can improve > performance even further. > > -- > Alan Eliasen > [email protected] > http://futureboy.us/
