[infinispan-dev] Providing a context for object de-serialization

[Mircea Markus]

----- Original Message -----
> From: "Sanne Grinovero" <sanne at infinispan.org>
> To: "infinispan -Dev List" <infinispan-dev at 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).