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@jboss.org]
Sent: 03 January 2007 17:26
To: Brian Stansberry
Cc: Galder Zamarreno; jbosscache-dev(a)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(a)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.