[infinispan-dev] Interceptor stack for local caches

[Emmanuel Bernard]

Ah. Tristan told me these plans are already in motion in stages. 

> On 22 juin 2015, at 08:09, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
> Pushing the idea further, you can actually make the CacheImpl specifically tailored to the configuration of a given cache by using ASM or anything that lets you build a class at runtime.
> That way, in this specialized implementation, all the interceptorImpl.before() and interceptorImpl.after() are specific non megamorphic calls that are optimizable and inline-able by the VM.
> 
> And you don’t suffer for the maintenance overhead that Radim was pointing at.
> 
> All of these ideas rely on a split of the interceptor logic into before() and after() methods.
> 
> Emmanuel
> 
>> On 22 Jun 2015, at 07:47, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> 
>> 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
>> 
>> _______________________________________________
>> 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