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