On May 21 2013, at 20:20 , Joseph Darcy wrote:
> 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.
Yes, quite possibly overkill for this test.
> 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 Long.MIN_VALUE was used as a terminator rather than as a prime. I have
changed the loop processing so that a terminator value is not needed.
> 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.)
Integer.MAX_VALUE now added along with some other primes near powers of two
boundaries.
Updated webrev:
http://cr.openjdk.java.net/~mduigou/JDK-8007398/3/webrev/
Thanks!
Mike
> -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
>
