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

[Sanne Grinovero]

On 27 June 2012 12:57, Mircea Markus <mmarkus at redhat.com> wrote:
>
>
> ----- 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).

right; in this specific case an enum would be nice, but it's just an
example I'm making up to save you from a gory explanation of OGM
internals, and the available types are not known the the
application at compile time but depend on the schema being used.