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

[Galder Zamarreno]

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 at 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 at 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 at 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
> 

-- 
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jbmar-r174.jps
Type: application/octet-stream
Size: 229322 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20090508/aa661763/attachment-0001.obj