wjc> I'm developing an obsession with getting rid of unnecessary
wjc> copies during response processing.
A patch for this is attached to bug SOAP-166:
http://nagoya.apache.org/jira/browse/SOAP-166
I'd appreciate it if anyone who can would give it a try and report pro
or con. For me, it gave
wjc> I'm developing an obsession with getting rid of unnecessary
wjc> copies during response processing.
To refresh your memories, I'm working on a patch that will allow
streaming the response payload directly into the XML parser inside
Call.invoke(), and I think I can also have a real stream insi
wjc> I ran a series of tests where the response payload varied in 10
wjc> steps from just under 200 kbytes to just under 2 mbytes
wjc> The difference in collectible memory footprint is a bigger
wjc> mystery, though.
wjc> For example, at the 1 mbyte payload step, the difference is about
wjc> 9 mby
wjc> I'm developing an obsession with getting rid of unnecessary
wjc> copies during response processing.
I got a chance to work on this over the weekend, and things went well.
(I have it working perfectly for the case that I care about, but I
haven't yet proved to myself that I didn't goof up case
sn> One thing I notice. In B you say "pass a MimeBodyPart
sn> (constructed from a DataSource in turn constructed from the
sn> original SocketInputStream)" and in D you say "where that
sn> InputSource would be constructed from the original
sn> SocketInputStream". Since you can only read the InputS
From: "WJCarpenter" <[EMAIL PROTECTED]>
To: "soap-dev" <[EMAIL PROTECTED]>
Sent: Friday, February 27, 2004 8:11 PM
Subject: eliminating one or two in memory copies of the response payload
I'm developing an obsession with getting rid of unnecessary copies
during r
I'm developing an obsession with getting rid of unnecessary copies
during response processing. I believe the most common case still has
two in-memory versions of the response payload (before the parsing is
done, which you could count as a 3rd version). I also think that in
the most common case at
