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:
MyComparator.compare(Object, Object) 19670ms
\-> MyComparator.compare(Integer, Integer) 10229ms
\-> Self Time 3001ms
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
Subclassability is a problem with "value-oriented" computing.
If security or extreme reliability is a concern, then
existing apis that took Integers or Strings as arguments would
have to make defensive copies on import or export, as they have
to do with arrays today. Since existing classes depend
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
>
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 still thi
My understanding is that this has nothing to do with performance.
Certain classes, such as String, as declared final for security reasons.
In the case of Integer I would suggest using composition. It's not as
nice but it'll work.
Gili
Nick Radov wrote:
Is it still necessary for the cor
Is it still necessary for the core Java classes such as java.lang.Integer
to be declared final? I understand that may have been necessary in the
early days for performance reasons, but modern JVMs no longer provide much
of a performance benefit for final classes. For certain applications it
wou
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
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:
/**
* Compares two keys using the correct comparison method for th
On Sat, Jan 05, 2008 at 08:01:35PM +0800, zhang Jackie wrote:
> Hi, everyone!
> Recently ,I want to have a performance comparision on RMI and my own
> version with little changes. Can you give me some microbenchmarks and some
> other suites used for estimate the performance of RMI? I googled
Clemens Eisserer wrote:
:
PS: The striding+GetPrimitive... is even used by NIO for copying
java-arrays into direct-ByteBuffers:
while (length > 0) {
size = (length > MBYTE ? MBYTE : length);
GETCRITICAL(bytes, env, dst);
memcpy(bytes + dstPos, (void *)srcAddr, size);
13 matches
Mail list logo
