[jbosscache-dev] VAM in JDBCCacheLoader : performance numbers andanalysis

[Galder Zamarreno]

Thanks for the feedback :)

I've found the test Bela's referring to. I'll use that as starting point to create one for VAM.

Cheers,

Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat

IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/

-----Original Message-----
From: Manik Surtani [mailto:manik at jboss.org] 
Sent: 03 January 2007 17:26
To: Brian Stansberry
Cc: Galder Zamarreno; jbosscache-dev at lists.jboss.org
Subject: Re: [jbosscache-dev] VAM in JDBCCacheLoader : performance numbers andanalysis

On 3 Jan 2007, at 16:17, Brian Stansberry wrote:

> jbosscache-dev-bounces at lists.jboss.org wrote:
>> On 28 Dec 2006, at 00:05, Galder Zamarreno wrote:airs here.
>
> <snip>
>
>>> Looking a bit deeper with the profiler, I have seen that
>>> TreeCacheMarshaller200 takes ages marshalling a map containing  
>>> string
>>> key/value pairs. Is this expected? We're adding quite a few  
>>> things to
>>> a simple String/String map, such as versioning and reference
>>> information. Compared to standard writeObject in HashMap,
>>> TreeCacheMarshaller200 spends quite a bit of time mantaining/
>>> updating a reference map.
>>
>> It is possible that such a reference map is meaningless in
>> the case of writing to a cache loader.  It makes sense
>> streaming on the wire for an RPC call though.  So maybe there
>> needs to be an overloaded form of objectTo|FromByteBuffer
>> that could disable the ref map?
>>
>
> Isn't that map used to ensure only a single copy of a
> multiple-referenced object survives serialization?  I'd think correct
> behavior for that would be critical no matter where it's done.
>

Good point, forget what I said. :-)  This is actually a side-effect  
(although a very correct one) - the original intention was to  
minimise large objects being duped in a stream.