On 11/30/2015 08:17 PM, Dan Berindei 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 admit that I was thinking more about non-tx caches, I would have to re-check what maps are written tx mode. Please, let's focus on non-tx. However I probably don't comprehend your answer completely. I am not talking that much about reading something from the context, but reads from these concurrent maps (these can be always somehow cached in the context), but about writes. > > 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. Maybe I am oversimplifying that - all the components would modify the shared record, and once the record becomes empty, it's removed. It's just a logical OR on these collections. > > 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. Datapoint noted. But if there's application using embedded Infinispan, it's quite likely that the app is CPU-bound, and Infinispan becomes, too. We're not optimizing for benchmarks but apps. Though, I can see that if server is not CPU bound, it won't make much difference. Thanks for your opinions, guys - if Will will remove the expiration registration, this idea is void (is anyone really using L1?). We'll see how this will end up. Radim > > Cheers > Dan > > > On Fri, Nov 27, 2015 at 11:28 AM, Radim Vansa <[email protected]> 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 <[email protected]> >> JBoss Performance Team >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <[email protected]> JBoss Performance Team _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
