Hello Mike,
The TestNG data provider framework is unfamiliar to me, so my first
reaction is that it is overkill for this problem as opposed to a one-off
approach, but that may be driven my lack of experience with it.
However, in the test code
153 private static final long[] SOME_PRIMES = {
154 3L, 5L, 7L, 11L, 13L, 17L, 19L, 23L, 29L, 31L, 37L, 41L,
43L, 47L, 53L,
155 59L, 61L, 71L, 73L, 79L, Long.MIN_VALUE };
the name of the array is incorrect since Long.MIN_VALUE = -2^63 which is
composite. Perhaps you were thinking of Integer.MAX_VALUE which is a
Mersenne prime? (2^61 -1 is a Mersenne prime; 2^63 - 1 is not.)
-Joe
On 5/21/2013 3:45 PM, Mike Duigou wrote:
Ping!
I need a final review on this issue.
Thanks,
Mike
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
