Also, lets please move this discussion to infinispan-dev…
On 25 Jan 2012, at 17:57, Dan Berindei wrote: > On Wed, Jan 25, 2012 at 6:32 PM, Sanne Grinovero <sa...@infinispan.org> wrote: >> On 25 January 2012 15:56, Dan Berindei <dan.berin...@gmail.com> wrote: >>> On Wed, Jan 25, 2012 at 3:16 PM, Sanne Grinovero <sa...@infinispan.org> >>> wrote: >>>> >>>> - ComponentRegistry.getComponent # can't we make sure this is not >>>> needed at runtime, or create direct accessors for the hottest ones, >>>> like Configuration.class ? I'll make a proposal and measure it. >>>> >>> >>> I had an idea of registering lots of CacheInboundInvocationHandlers in >>> CommandAwareRpcDispatcher instead of a single global >>> InboundInvocationHandler but I never implemented it. Are you thinking >>> along the same lines? >> >> >> No I've been patching CacheRpcCommandExternalizer instead. But please >> change that one if you have an idea. >> > > Ok, I'll do that. > >> >>>> - DefaultConsistentHash.isKeyLocalToAddress # Should be possible to >>>> speed up this one >>>> >>> >>> I didn't think of any optimization specific for isKeyLocalToAddress, >>> but we could precompute the list of owners for each hash wheel >>> "segment" and store that in the positionValues array instead of a >>> single address. It would get kind of expensive with huge numbers of >>> virtual nodes, so it would be nice if we could prevent the users from >>> using thousands of virtual nodes. >>> >>> Address interning could help us somewhat, if we could eliminate the >>> equals() calls with reference equality checks. >> >> Right, but it means that all Address should be created via the same >> service, including unmarshalled ones. >> Would be nice doing it, but sounds like dangerous if not doing an >> extensive refactoring. >> I'd try something like this by introducing a new type, mandate the >> type on the API, and do this possibly after changing the Address >> collections to an ad-hoc Collection as suggested last week; not sure >> yet how it would look like, but let's evaluate options after the >> custom collections is in place. >> > > I was actually thinking knowing that a1 != a2 => !a1.equals(a2) would > enable us to use even more efficient custom collections. > But I agree that replacing all addresses with interned ones is not an easy > task. > >>>> - boolean >>>> org.infinispan.transaction.xa.GlobalTransaction.equals(java.lang.Object) >>>> # let's see if we can do something about this. >>>> >>> >>> Checking the address is more expensive than checking the id, we should >>> check the id first. >>> Other than that, the only thing we can do is call it less often :) >> >> And idea on "less often" ? >> > > Nope, no idea I'm afraid. > >>> >>>> - jni_GetObjectField # would like to know where this is coming from >>>> >>> >>> It looks like it's PlainDatagramSocketImpl.send and receive: >>> >>> 6184 0.2442 libnet.so libnet.so >>> Java_java_net_PlainDatagramSocketImpl_send >>> 7483 34.3556 libjvm.so libnet.so >>> jni_GetObjectField >>> >>> 3849 0.1520 libnet.so libnet.so >>> Java_java_net_PlainDatagramSocketImpl_receive0 >>> 8221 34.7773 libjvm.so libnet.so >>> jni_GetObjectField >> >> Right, that's likely. Would like to make sure. >> > > This is certainly a big part of where it's coming from - but perhaps > there are other places as well. > >> >>> I also have a question, are you using virtual nodes? We should enable >>> it in our perf tests (say with numVirtualNodes = 10), I suspect it >>> will make DCH.locate and DCH.isKeyLocalToAddress even slower. >> >> We've discussed VNodes a lot on IRC, you should join us. >> [My tests where without, but have already applied the patch to enable it] >> > > I'm also going to update VNodesCHPerfTest to look closer at key distribution. > > Cheers > Dan -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev