RFR: 8196334: Optimize UUID#fromString

Claes Redestad claes.redestad at oracle.com
Sun Mar 8 14:05:43 UTC 2020


Hi Peter,

sorry about defaulting to throughput measurement - while average time
has its advantages (especially on nanobenchmarks), most benchmarks are
intuitively "higher is better", so I lean that way by old habit.

Thanks for trying out your ideas, though! It's important we try out and
report the result of reasonable alternatives, even when they fall short.
I've done a number of experiments here that I should have probably made
a note of somewhere...

Thanks!

/Claes

On 2020-03-08 12:59, Peter Levart wrote:
> Sorry, bash this.
> 
> I just noticed that the units used in benchmark are ops/us and that the 
> best performing code is the one which is in place now.
> 
> I usually use ns/op as a unit in JMH benchmarks, so this led me to false 
> belief that alternatives are better performing where in fact are worse.
> 
> Sorry for noise.
> 
> Regards, Peter
> 
> 
> On 3/8/20 12:46 PM, Peter Levart wrote:
>> Hi,
>>
>> When I noticed this optimization, I had some ideas how to push this 
>> even further, but only now had some time to try them out.
>>
>> Here are some incremental improvements [1] to the already brilliant 
>> idea with the following JMH results (the baseline is JDK build with 
>> patch for 8196334 already applied):
>>
>> Benchmark                     (size)   Mode  Cnt   Score   Error Units
>> UUIDBench.uuidFromString       20000  thrpt    5  37.344 ± 0.257 ops/us
>> UUIDBench.uuidFromStringAlt1   20000  thrpt    5  29.069 ± 0.137 ops/us
>> UUIDBench.uuidFromStringAlt2   20000  thrpt    5  27.308 ± 0.204 ops/us
>> UUIDBench.uuidFromStringAlt3   20000  thrpt    5  23.195 ± 0.885 ops/us
>>
>> As can be seen, the trick was to eliminate branches (alt1, alt2) and 
>> to reduce the number of operations (shifts) in alt3. One last trick in 
>> alt3 was to use the array length in a check that is then fused with 
>> array index bounds check (I think) so that we get one of them for free.
>>
>> What do you think? Is this good enough to warrant another change? As 
>> you can see, I haven't prepared the patch yet,  just benchmark.
>>
>> Regards, Peter
>>
>> [1] 
>> http://cr.openjdk.java.net/~plevart/jdk-dev/8196334_UUID.fromString/UUIDBench.java 
>>
>>
>>
>> On 3/2/20 8:26 AM, Claes Redestad wrote:
>>> On 2020-03-02 08:14, Alan Bateman wrote:
>>>>>
>>>>> http://cr.openjdk.java.net/~redestad/8196334/open.02/
>>>> Looks good.
>>>
>>> Thanks - pushed!
>>>
>>> /Claes
>>
> 


More information about the core-libs-dev mailing list