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 >> >
