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

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