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

[Mike Duigou]

I've cleaned up the test some with feedback from Brian Goetz:

http://cr.openjdk.java.net/~mduigou/JDK-8007398/3/webrev/

On May 16 2013, at 14:02 , Mike Duigou wrote:

> 
> On May 15 2013, at 19:09 , Joseph Darcy wrote:
> 
>> Hi Mike,
>> 
>> Looks fine. Are you satisfied with the test coverage provided by the existing regression tests?
> 
> I hadn't actually looked but it turns out the answer was "No, certainly not".
> 
> I built a set of tests across all of the primitive integral types that compares the results of various toString operations against BigInteger.toString(radix). This is not ideal because BigInteger.toString(radix) is implemented via Long.toString(l, radix). If there's a different exemplar provider which generates results entirely independently of the code paths to be tested the test can be fairly easily switched to use that.
> 
> If anyone has suggestions for interesting test cases in numberProvider() I would also be interested in hearing about those.
> 
> http://cr.openjdk.java.net/~mduigou/JDK-8007398/2/webrev/
> 
> Mike
> 
>> 
>> -Joe
>> 
>> On 5/15/2013 6: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/
>>> 
>>> I've done microbenchmarking of using digits table vs calculating digits, previously mentioned in <http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/016526.html>, and found that using the digits table was still faster.
>>> 
>>> I've also benchmarked removing the offset param from formatUnsignedLong() and simplifying the loop termination logic but neither of these turned out to have little benefit.
>>> 
>>> 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.
>>> 
>>> We'll get back to 8006627 soon enough. (I have been tempted to split it again into parsing and formatting).
>>> 
>>> Thanks,
>>> 
>>> Mike
>> 
>