[infinispan-dev] Re: JProfiler snapshots for Infinispan+JBMAR

OK, I tried out a few things. You might want to try introducing these one at a time (i.e. update up to rev 173, then 174, then 175 and see how each one does). In particular, I think 175 has just as much chance of slowing things down as speeding them up - either you're getting tons of collisions in the hash table or the profiler is skewing the results there (maybe try filtering out org.jboss.marshalling.util.IdentityIntMap and java.lang.System to see if that gives a different picture). I feel pretty good about 173 and 174 though I think the profiler will skew 173 unless you have that UTFUtils filter installed. If 175 slows things down (outside of the profiler), let me know and I'll revert it. None of my tests showed much difference but I don't have any good benchmarks that really exercise that code right now. There's a couple things left to try yet, like looking at replacing ConcurrentReferenceHashMap (assuming that isn't the profiler again). ------------------------------------------------------------------------ r175 | david.lloyd(a)jboss.com | 2009-05-08 00:17:46 -0500 (Fri, 08 May 2009) | 1 line Try a trick to decrease the liklihood of collisions ------------------------------------------------------------------------ r174 | david.lloyd(a)jboss.com | 2009-05-08 00:04:39 -0500 (Fri, 08 May 2009) | 1 line Replacement caching is not economical; the cost is one extra hash table get for non-replaced objects, two hash table gets (total) for replaced objects. Removing the cache gets rid of the cost for non-replaced objects, while replaced objects now have to be replaced again before the single hash table hit. ------------------------------------------------------------------------ r173 | david.lloyd(a)jboss.com | 2009-05-07 23:44:52 -0500 (Thu, 07 May 2009) | 1 line JBMAR-52 - Avoid extra copy of char array (1.5 of 2) ------------------------------------------------------------------------ - DML