Proposal for improving performance of TreeMap and others

cowwoc cowwoc at
Mon Jan 7 23:51:52 UTC 2008

Something very weird is going on. I tried profiling a minimal testcase and
there is a considerable amount of "missing time". I am using a dev build of
Netbeans 6.1 and it says:, Object) 19670ms
\->, Integer) 10229ms
  \-> Self Time 3001ms
  \-> Integer.compareTo(Integer) 1575ms
\-> Self Time 3788ms

I spot at least three problems:

1) The individual item times do not add up to the total (but they do for
other stack-traces).
2) self-time consumes more CPU than Integer.compareTo()
even though it only invokes a method while the latter does actual
3) Why is extra time consumed moving from,
Object) to (Integer, Integer)? It looks like Generics is doing something at
runtime which consumes a large amount of cpu.


Clemens Eisserer wrote:
> 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
>> faster?
> I don't think it will optimize the null-check away, however it is so
> cheap that it most likely will not weight at all, compared to all the
> other operations happening there. Its maybe 5 instructions compared to
> thousands or even more.
> -Xverify:none only disables bytecode verification at class-loading
> time and has no influence (as far as I know) on the performance of the
> generated code.
>> I still think that my proposed code is somehow more consistent/cleaner on
>> a
>> design-level but I guess that's just me :)
> I also like it more, its cleaner in my opinion :)
>> As an aside, are there standard benchmarks for testing the impact of this
>> change? I'd love to know whether it actually produces any performance
>> difference in practice.
>>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:
Sent from the OpenJDK Core Libraries mailing list archive at

More information about the core-libs-dev mailing list