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

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.


   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

More information about the core-libs-dev mailing list