[prev in list] [next in list] [prev in thread] [next in thread] 

List:       soap-dev
Subject:    RE: eliminating one or two in memory copies of the response payload
From:       bill-soap () carpenter ! ORG (WJCarpenter)
Date:       2004-03-19 17:39:15
Message-ID: 3228-Fri19Mar2004093915-0800-bill () carpenter ! ORG
[Download RAW message or body]

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 inside the
DataSource returned by Message.receive().  A little while back, I
reported time improvements of about 5% for this in single-threaded
testing.  Now that I've done more organized testing, the difference is
more in the ballpark of 10-15% for time and 4-5x payload size
difference in scratch memory footprint (a 100 byte response on the
wire translates to a 100 character response in memory, which is 200
bytes in memory; the difference in the example would be 800-100
bytes).

In other words, a respectable improvement in both factors.

It's mostly easy to make it completely transparent to stream response
payloads to the receiver, but it can't be 100% because of the
following factors, which leads to a couple of upward compatibility
questions for interested parties:

* As I mentioned in my original message, there's one place inside
Call.invoke where a scratch copy of the response is tucked away "just
in case" for possible use in exception text.  My guess is nobody
really cares about that case.

* SOAPContext contains a protected field "rootPartString" that holds a
reference to the response payload as a String.  The field is not
referenced outside its class, so the only upward compatibility problem
is for subclasses of SOAPContext.  There are no subclasses of
SOAPContext in the Apache SOAP distribution.  There is also an
accessor method, "getEnvelope", which returns the same thing.  So, is
this field (and the dozen or so other fields) protected for the
benefit of subclasses, or was it just somebody's habit to code fields
as protected?  More importantly, does it matter if I get rid of that
particular field?  My guess is that it doesn't matter.

* Same question as above for TransportMessage, except it contains two
such protected fields.  "bytes" is a reference to the payload as a
byte[] and "envelope" is a reference to it as a String (yeah, I
thought the same thing about that :-).  There are no subclasses of
TransportMessage in the Apache SOAP distribution.  So, likewise, were
those fields intentionally "protected", and does it matter if I get
rid of them.  Again, my guess is that it doesn't matter.

* Class TransportMessage implements Serializable.  Hrmmm?  Any
particular reason for this?  My guess is that it's completely
extraneous and a TransportMessage is never actually serialized (in the
java.io.Serializable sense).  The reason I make that bold claim is
because one of the fields inside TransportMessage is a SOAPContext,
and SOAPContext does *not* implement Serializable, which means any
attempt to actually serialize TransportMessage would blow up.  So,
does this "implements Serializable" matter?  As I said, my guess is
not. (The reason I ask is because I want to add another field inside
TransportMessage, and I don't want to go to the bother of properly
implementing serialization in that referenced class.)

Finally, a more general sort of question:  What's the confidence in
the Apache SOAP test code in detecting regression errors?  The change
I'm making is not conceptually complicated, but it is fairly invasive,
mostly because of the use of the fields mentioned above.  Not counting
a new utility class, the unified patch is about 27k, and a lot of that
is couple-of-lines changes scattered around.  I'm pretty confident in
being right for the code paths I test directly, but there are code
paths I don't test at all (and perhaps am not even aware of).  Is
running the test code likely to shake out any problems?
-- 
bill@carpenter.ORG (WJCarpenter)    PGP 0x91865119
38 95 1B 69 C9 C6 3D 25    73 46 32 04 69 D6 ED F3

[prev in list] [next in list] [prev in thread] [next in thread]