Re: [infinispan-dev] Interceptor stack for local caches
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