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

Galder, would you mind switching to trunk and trying that version (unofficial 1.2.0.CR1 - yes I *promise* I'll fix the versioning and get a source blob built asap!)? - DML On 05/08/2009 12:09 PM, Galder Zamarreno wrote: > Profiler data with JBMAR r174 > > Galder Zamarreno wrote: >> Hi David, >> >> Please find attach graphs belonging to two runs that compare: >> >> infinispan-4.0.0(repl-sync) - home grown marshalling layer >> infinispan-4.0.0(repl-sync-jbmar) - infinispan + jbmar 1.1.2 >> infinispan-4.0.0(repl-sync-jbmar)-rXYZ - infinispan + jbmar with >> revision >> >> Not sure what's the conclusion here tbh. The results of 1.1.2 almost >> look opposite in each test. >> >> I've also attached some information from previously run profiling >> sessions with a couple of local machines we have in Neuchatel. I >> profiled the faster of the two machines. >> >> Actually, looking at this profiled data, these tests are for >> synchronous replicated caches but I see no traces of actually reading >> the stream, only writing to it, hmmmm. >> >> I'm adding Externalizers to class table and implementing >> marshaller/unmarshaller pooling as my next tasks. >> >> Regards, >> >> David M. Lloyd wrote: >>> 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 >> >