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 t
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.
S
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
On 2020-03-02 08:14, Alan Bateman wrote:
http://cr.openjdk.java.net/~redestad/8196334/open.02/
Looks good.
Thanks - pushed!
/Claes
On 01/03/2020 21:05, Claes Redestad wrote:
:
Filed https://bugs.openjdk.java.net/browse/JDK-8240266 to investigate
if we can improve the branch elimination in Character.digit and removed
the comment.
Also moved parse4Nibbles up before fromString and fixed the redundant
FQDN for Array:
http://c
On 2020-03-01 20:41, Alan Bateman wrote:
On 01/03/2020 18:19, Claes Redestad wrote:
:
After discussing it a bit offline, Andriy and I would like to simplify
the dash-checking code a bit to make it more clear, as there seems to be
no obvious performance drawback of simplifying to (ch1 == '-'
On 01/03/2020 18:19, Claes Redestad wrote:
:
After discussing it a bit offline, Andriy and I would like to simplify
the dash-checking code a bit to make it more clear, as there seems to be
no obvious performance drawback of simplifying to (ch1 == '-' && ...).
New webrev: http://cr.openjdk.java.
On 2020-02-29 00:58, Ivan Gerasimov wrote:
Sounds reasonable.
I think the current proposal is clearly a progress, so it looks good.
Ok!
After discussing it a bit offline, Andriy and I would like to simplify
the dash-checking code a bit to make it more clear, as there seems to be
no obvious
Sounds reasonable.
I think the current proposal is clearly a progress, so it looks good.
I agree that any further optimization can be considered within a
separate enhancement request.
With kind regards,
Ivan
On 2/28/20 2:59 PM, Claes Redestad wrote:
Hi Ivan,
I've considered trying it out,
Hi Ivan,
I've considered trying it out, but it gets complicated as we don't want
to penalize -XX:-UseCompactStrings.
I think adding special methods for UUID inside StringLatin1 is a step
in the wrong direction, but maybe there's something more generic we can
consider. However, short of adding St
Hi Claes and Andriy!
It looks good overall.
I wonder if it'll be even faster if the fast path were implemented in
StringLatin1 (for compact strings only) and was called via
SharedSecrets/JavaLangAccess?
Then, you could operate directly on bytes and avoid dealing with longs.
With kind regard
Hi all,
please review this patch to optimize UUID#fromString.
Jon Chambers originally proposed a patch that used a strict parser to
get a similar speed-up, but I failed to adapt it in a way that
could fall back to the less strict behavior while maintaining a
reasonable speed-up in the fast-path
12 matches
Mail list logo
