Re: [infinispan-dev] Interceptor stack for local caches

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(a)hibernate.org&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; >> JBoss Performance Team >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev