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