Re: [infinispan-dev] Allocation costs of TypeConverterDelegatingAdvancedCache

2017-06-01 Thread William Burns
On Thu, Jun 1, 2017 at 7:11 AM Dan Berindei wrote: > On Wed, May 31, 2017 at 10:05 PM, William Burns > wrote: > > Let me explain why it is there first :) This class was added for two main > > reasons: as a replacement for compatibility and for supporting equality > of > > byte[] object. What thi

Re: [infinispan-dev] Allocation costs of TypeConverterDelegatingAdvancedCache

2017-06-01 Thread William Burns
I think we may be confusing two different features. These changes are what I was hoping could be used as a basis for the transformers work (doesn't mean they will be). These changes were done before there was any discussions about transformers though, so they may not have the use cases covered. I t

Re: [infinispan-dev] Allocation costs of TypeConverterDelegatingAdvancedCache

2017-06-01 Thread Sanne Grinovero
Thanks all for the great explanations. +1 to try to avoid this. Could the transformation be performed lazily? We had a design meeting about transformers and that was a goal we had agreed on. For example in the Search case, I'm doing a getAll( keys ) just to return the objects in a sorted list bac

Re: [infinispan-dev] Allocation costs of TypeConverterDelegatingAdvancedCache

2017-06-01 Thread Dan Berindei
On Wed, May 31, 2017 at 10:05 PM, William Burns wrote: > Let me explain why it is there first :) This class was added for two main > reasons: as a replacement for compatibility and for supporting equality of > byte[] object. What this class does is at the user side is box the given > arguments (eg

Re: [infinispan-dev] Allocation costs of TypeConverterDelegatingAdvancedCache

2017-06-01 Thread Gustavo Fernandes
On Wed, May 31, 2017 at 8:05 PM, William Burns wrote: > Let me explain why it is there first :) This class was added for two main > reasons: as a replacement for compatibility and for supporting equality of > byte[] object. What this class does is at the user side is box the given > arguments (eg

Re: [infinispan-dev] Allocation costs of TypeConverterDelegatingAdvancedCache

2017-05-31 Thread William Burns
Let me explain why it is there first :) This class was added for two main reasons: as a replacement for compatibility and for supporting equality of byte[] object. What this class does is at the user side is box the given arguments (eg. byte[] -> WrappedByteArray) then the cache only ever deals wit

[infinispan-dev] Allocation costs of TypeConverterDelegatingAdvancedCache

2017-05-31 Thread Sanne Grinovero
Hi all, I've been running some benchmarks and for the fist time playing with Infinispan 9+, so please bear with me as I might shoot some dumb questions to the list in the following days. The need for TypeConverterDelegatingAdvancedCache to wrap most operations - especially "convertKeys" - is high