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

[Sanne Grinovero]

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.
Of course in this example just ordering name as first comparison makes
it unlikely unlikely enough to ever perform the second check, but
guessing the best order in a real world scenario is far more complex..
plus I have arrays of Strings to compare.


On 26 June 2012 20:05, 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 5:13:28 PM
>> Subject: [infinispan-dev] Providing a context for object de-serialization
>>
>> Imagine I have a value object which needs to be stored in Infinispan:
>>
>> class Person {
>>    final String nationality = ...
>>    final String fullName = ...
>>  [constructor]
>> }
>>
>> And now let's assume that - as you could expect - most Person
>> instances have the same value for the nationality String, but a
>> different name.
>>
>> I want to define a custom Externalizer for my type, but the current
>> Externalizer API doesn't allow to refer to some common application
>> context, which might be extremely useful to deserialize this Person
>> instance:
>>
>> we could avoid filling the memory of my Grid by having multiple
>> copies
>> of the nationality String repeated all over, when a String [1] could
>> be reused.
>>
>> Would it be a good idea to have the Externalizer instances have an
>> initialization phase receiving a ComponentRegistry, so I could look
>> up
>> some custom service to de-duplicate or otherwise optimize my
>> in-memory
>> data representation?
>> Personally I'd prefer to receive it injected via the constructor so
>> that I could use a final field when my custom Externalizer is
>> constructed.
> +1. That's pretty easy to achieve by registering the Externalizers into the ComponentRegistry (or simpler just run the component registry wiring code on each externalizer object in the ExternalizerTable). Unfortunately our internal dependency injection framework doesn't support c-tor injection yet.

Thanks:
https://issues.jboss.org/browse/ISPN-2133

Sanne