RE: Some performance measures

Hello I have found a new big performance reserve for those who uses Xerces 2 as a parser, almost for free coding Thinking why Xerces 2 takes so much time, and analyzing CPU time I have found that many time in xerces takes DefferedDocument... After reading xerces documentation I have found that

RE: Some performance measures

It may happen is that easier to implement a "Proxy" , which looks like Apache SOAP, but calls Apache AXIS... -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: Some performance measures

"Pavel Ausianik" <[EMAIL PROTECTED]> writes: > Switching to SAX is hardly possible for the current SOAP implemenation. The > main reason is that it will require changing too many APIs were DOM directly > used. IMHO it doesn't make any sense for Apache SOAP to go down this the SAX direction .. that

Re: Some performance measures

> Axis is SAX based .. Sorry, then. My mistake. I guess I must've misinterpreted some comments on the Axis list (which I don't follow as closely). -- To unsubscribe, e-mail: For additional commands, e-mail:

RE: Some performance measures

> -Original Message- > From: WJCarpenter [mailto:[EMAIL PROTECTED]] > Sent: Saturday, November 16, 2002 11:33 PM > To: [EMAIL PROTECTED] > Subject: RE: Some performance measures > > > > Thinking further about reasons it didn't improved for you - It may

Re: Some performance measures

"WJCarpenter" <[EMAIL PROTECTED]> writes: > > [[As a side note, it seems to me that doing a SAX deserialization > model is no more difficult than the DOM-based model we have now. I > completely understand why nobody has stepped up to that as an > *additional* effort for Apache SOAP, which is more

RE: Some performance measures

> 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 or

RE: Some performance measures

er 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 achievem

RE: Some performance measures

turday, 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 wit

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 f

Some performance measures

Hello, I have made some performance comparisons between soap 2.3.1 and my current code (including all my patches proposed), replacing separately client and server libs Here are results: Client 2.3.1, Server 2.3.1 100.842 96.701 Client current Server 2.3.1 92.733 89.186 Client 2.3.1 Server cu