Ah. Tristan told me these plans are already in motion in stages. > On 22 juin 2015, at 08:09, Emmanuel Bernard <emman...@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 <emman...@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 <emman...@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 <rva...@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 <rva...@redhat.com> >>>> JBoss Performance Team >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev