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

Alan Eliasen eliasen at mindspring.com
Fri May 17 03:52:02 UTC 2013

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?

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(). 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