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

[David M. Lloyd]

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