RFR : 8007398 : (S) Performance improvements for Int/Long toString() at Radix 2, 8, 16 (original) (raw)

Mike Duigou mike.duigou at oracle.com
Fri May 17 23:11:02 UTC 2013

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 eliasen at mindspring.com http://futureboy.us/

More information about the core-libs-dev mailing list