It's likely what you are observing in #2 & #3 and possibly in #1 also is
an artifact of inlining and possibly other JIT (dynamic) compiler
optimizations.
You might consider re-running your experiment with inlining disabled,
-XX:-Inlining.
Or, alternatively try running your experiment (with i
That's good news, I guess ;) because in my minimal testcase that had
nothing to do with TreeMap it looked like using a Comparator to wrap
natural ordering degraded performance by an order of magnitude... which
is really bad :)
If the same isn't true for the actual TreeMap this change might
actice.
>>From my experience i would rather guess that you won't notice the
> change, noise will be higher.
>
> lg Clemens
>
>
--
View this message in context:
http://www.nabble.com/Proposal-for-improving-performance-of-TreeMap-and-others-tp14673283p14679084.html
Sent from the OpenJDK Core Libraries mailing list archive at Nabble.com.
Clemens Eisserer a écrit :
Hi cowwoc,
I guess you're right. It is probably as likely that the JIT will optimize
away the null check as it is that it will optimize away the
NullPointerException check. One exception, though, is when production
systems run using -Xverify:none. In such a case, w
Hi cowwoc,
> I guess you're right. It is probably as likely that the JIT will optimize
> away the null check as it is that it will optimize away the
> NullPointerException check. One exception, though, is when production
> systems run using -Xverify:none. In such a case, wouldn't my approach run
>
; return ((Comparable) first).compareTo(second);
>> }
>> });
>>
>> This solution should be backwards compatible while improving performance.
>> At
>> least, that's my guess. There is always the chance that the JIT is smart
>> enough to optimize away this comparison but I'd rather not rely on JIT
>> implementation details. I also believe the resulting code is more
>> readable.
>>
>> What do you think?
>
>
--
View this message in context:
http://www.nabble.com/Proposal-for-improving-performance-of-TreeMap-and-others-tp14673283p14676918.html
Sent from the OpenJDK Core Libraries mailing list archive at Nabble.com.
The authors of TreeMap have thought about
eliding comparator null checks:
/**
* Version of getEntry using comparator. Split off from getEntry
* for performance. (This is not worth doing for most methods,
* that are less dependent on comparator performance, but is
* worthwh
cowwoc wrote:
I noticed that TreeMap (and maybe other classes) require a user to either
pass in a Comparator or ensure that all keys must implement Comparable. The
TreeMap code then uses a utility method whenever it needs to compare two
keys:
I'm not going to comment about performance, but ther
> This solution should be backwards compatible while improving performance. At
> least, that's my guess. There is always the chance that the JIT is smart
> enough to optimize away this comparison but I'd rather not rely on JIT
> implementation details. I also believe the resulting code is more read
o optimize away this comparison but I'd rather not rely on JIT
implementation details. I also believe the resulting code is more readable.
What do you think?
--
View this message in context:
http://www.nabble.com/Proposal-for-improving-performance-of-TreeMap-and-others-tp14673283p14673283.html
S
10 matches
Mail list logo
