----- Original Message -----
From: "Sanne Grinovero" <sanne(a)infinispan.org>
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
Sent: Tuesday, June 26, 2012 8:59:00 PM
Subject: Re: [infinispan-dev] Providing a context for object de-serialization
I'll mention another good reason why this would be awesome (on top of
memory consumption):
In one of the OGM tests we highlighted quite some cost on the
EntityKey#equals method. EntityKey is the key used to store some of
the most frequently accessed elements from the Cache, so no wonder
this equals method is quite stressed.
We improved it a bit with a carefully crafted equals implementation,
still it has to compare several fields, of which most are the same in
most cases.
Back to our Person example, this would allow me to change an #equals
implementation from
[...]
if (name == null) {
if (other.name != null)
return false;
} else if (!name.equals(other.name))
return false;
if (nationality == null) {
if (other.nationality != null)
return false;
} else if (!nationality.equals(other.nationality))
return false;
Into
if (nationality != other.nationality)
return false;
if (name == null) {
if (other.name != null)
return false;
} else if (!name.equals(other.name))
return false;
See the dirty trick? String comparison isn't exactly cheap, if you
have to run it on hundreds of elements.
yep, especially when the strings are actual
equals, it takes O(String.length) to compare them.
In your example with nationality there's a high chance they are, so equal should be
costly indeed.
(I think I'd model nationality as an enum though, but still excellent point).