[infinispan-dev] Interceptor stack for local caches
Emmanuel Bernard
emmanuel at hibernate.org
Mon Jun 22 07:47:37 EDT 2015
BTW, a generic interface based call to interceptors is hard to optimize by the VM AFAIU.
So having a few specialized implementations of CacheImpl that do hard code the calls to specific interceptor implementations (the 2 methods split ones) would make a lot of sense to me for a handful of selected cases like you are describing Radim.
> On 22 juin 2015, at 07:42, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
> I am no expect at all of the code base.
> Wouldn't returning LocalCacheImpl happening in very very specific cases and thus not be of quite limited use?
>
> And that resonates with the discussion of splitting the interceptor logic into before and after methods. And keeping the state not in the interceptor but in a type less stack passed to these methods. That would probably reduce the unnecessary allocation you are seeing. This also opened the doors for moving locks outside the execution thread AFAIR.
>
> Was this approach ever put on paper even as a few paragraphs somewhere ?
>
>> On 22 juin 2015, at 07:18, Radim Vansa <rvansa at redhat.com> wrote:
>>
>> Hi,
>>
>> few weeks ago I was looking into performance of local cache when
>> compared to basic concurrent hash map, or data container. I can't find
>> the exact results now, but the difference was in order of magnitude -
>> IIRC concurrent hash map was about 20x faster than local cache. There
>> was no 'bottleneck', but the versatile Infinispan design of commands
>> traversing through interceptor stack brings some overhead (e.g.
>> allocation costs with each invocation, not only for writes) while in
>> some use cases it is not necessary to keep this complexity. The use case
>> I am looking for is caching in Hibernate ORM, which basically requires
>> only map with eviction, expiration and transactions in some cases. No
>> need for cache stores, statistics etc. So far I've found ways to remove
>> few interceptors [1], but it's few percent, not hundreds of percent
>> where I would ideally aim.
>>
>> Therefore, I was considering about an option to inspect cache
>> configuration and in suitable cases return LocalCacheImpl that would get
>> rid of the burden: no interceptor stack, no commands instantiation. This
>> would be transparent to the user. I understand that it will increase
>> maintenance costs, but it still seems better to me to have it under
>> wings of Infinispan as caching solution rather than separate project, as
>> it can share a lot of the codebase.
>>
>> Do you think that this idea makes sense, or is it just too wild? Do you
>> think I will crash when trying to implement this?
>>
>> Radim
>>
>> [1] https://issues.jboss.org/browse/ISPN-5542
>>
>> --
>> Radim Vansa <rvansa at redhat.com>
>> JBoss Performance Team
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
More information about the infinispan-dev
mailing list