Wouldn't it be an interesting compromise to make sure we calculate
things like the key's hash only once?
On 30 November 2015 at 21:54, William Burns <mudokonman(a)gmail.com> wrote:
I am not sure there is an easy way to consolidate these into a single
map,
since some of these are written to on reads, some on writes and sometimes
conditionally written to. And then as Dan said they are cleaned up at
different times possibly.
We could do something like states (based on which ones would have written to
the map), but I think it will get quite complex, especially if we ever add
more of these map type requirement.
On a similar note, I had actually thought of possibly moving the expiration
check out of the data container and into the entry wrapping interceptor or
the likes. This would allow for us to remove the expiration map completely
since we could only raise the extra expiration commands on a read and not
writes. But this would change the API and I am thinking we can only do this
for 9.0.
On Mon, Nov 30, 2015 at 2:18 PM Dan Berindei <dan.berindei(a)gmail.com> wrote:
>
> The first problem that comes to mind is that context entries are also
> stored in a map, at least in transactional mode. So access through the
> context would only be faster in non-tx caches, in tx caches it would
> not add any benefits.
>
> I also have some trouble imagining how these temporary entries would
> be released, since locks, L1 requestors, L1 synchronizers, and write
> registrations all have their own rules for cleaning up.
>
> Finally, I'm not sure how much this would help. I actually removed the
> write registration for everything except RemoveExpiredCommand when
> testing the HotRod server performance, but I didn't get any
> significant improvement on my machine. Which was kind of expected,
> since the benchmark doesn't seem to be CPU-bound, and JFR was showing
> it with < 1.5% of CPU.
>
>
> Cheers
> Dan
>
>
> On Fri, Nov 27, 2015 at 11:28 AM, Radim Vansa <rvansa(a)redhat.com> wrote:
> > No thoughts at all? @wburns, could I have your view on this?
> >
> > Thanks
> >
> > Radim
> >
> > On 11/23/2015 04:26 PM, Radim Vansa wrote:
> >> Hi again,
> >>
> >> examining some flamegraphs I've found out that recently the
> >> ExpirationInterceptor has been added, which registers ongoing write in
> >> a
> >> hashmap. So at this point we have a map for locks, map for writes used
> >> for expiration, another two key-addressed maps in L1ManagerImpl and one
> >> in L1NonTxInterceptor and maybe another maps elsewhere.
> >>
> >> This makes me think that we could spare map lookups and expensive
> >> writes
> >> by providing *single map for temporary per-key data*. A reference to
> >> the
> >> entry could be stored in the context to save the lookups. An extreme
> >> case would be to put this into DataContainer, but I think that this
> >> would prove too tricky in practice.
> >>
> >> A downside would be the loss of encapsulation (any component could
> >> theoretically access e.g. locks), but I don't find that too dramatic.
> >>
> >> WDYT?
> >>
> >> Radim
> >>
> >
> >
> > --
> > 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