Thinking further about reasons it didn't improved for you - It may happen that InputStream.read + DocumentBuilder.parse for huge response takes so much of the whole process , so other parts just do not important and any difference is just a measurement error. Most changes were done in order to rather improve continuous operations running many times.
> -----Original Message----- > From: WJCarpenter [mailto:[EMAIL PROTECTED]] > Sent: Saturday, November 16, 2002 6:59 PM > To: [EMAIL PROTECTED] > Subject: Re: Some performance measures > > > > Client achievements are less significally - up 10-15% to > current code, > > or -8-9 sec. Probably client code was less affected... > > This is consistent with informal client-side comparisons I've done > along the same lines. The last I did was with the nightly Apache > SOAP from 2002-11-13. We saw a few percent improvement for > some cases, > but we actually had a few cases where it was a few percent worse. > (We have a case with 5 MB of tiny RPC SOAP-encoded response with lots > of tiny elements. We have another case of a 2 MB RPC SOAP-encoded > response consisting of a single huge string wrapped inside CDATA.) > > Keep up the good detective work, though! It's still much easier for > us (and I presume lots of other people) to move to a newer Apache SOAP > than to migrate to Apache Axis for existing projects. > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
