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