-
Enhancement
-
Resolution: Done
-
Major
-
None
-
None
-
None
Basically, the difference between Hot Rod then (dc6708f) and now (6058358) is: 32 bytes, which is: new metadata object, a reference to it, and 2 unusued longs for immortal entries.
With embedded metadata (~191 bytes per entry): https://dl.dropboxusercontent.com/u/6148072/with-embedded.png
With versioned entries (~159 bytes per entry): https://dl.dropboxusercontent.com/u/6148072/with-versioned.png
And there's more: we have internal cache entries that have a reference to internal cache values, per entry. This is useful for some cases (cache stores…etc), but this extra reference to the value, plus the value object itself, is 16 bytes (how useful is it really to have a separate value instance to keep just the value? Needs reassessing its usefulness...).
So really, I think the minimum Hot Rod overhead we should aim for is ~143 bytes. If each server module could define what the ICE class (well, classes to cover all immortal, mortal…etc cases) to use, which is purely designed for their servers (i.e. hot rod just needs: value + version; memcached needs: value + version + flags), we could get to this level…
You still want the metadata to be passed from the client, but for those specialised use cases in Infinispan, we could have a mapping between the metadata type and the type of ICEs created…
- relates to
-
ISPN-3311 org.infinispan.lifecycle.ModuleLifecycle service definitions missing from Lucene Directory jar
- Closed