Your results agree with mine: the transform is slower than the document
builder. Maybe it's just the Xalan/Xerces implementation, as I used
those as well.
The problem with not using reflection is that it is hard to predict
where the NoClassDefFoundError exceptions will be thrown. The JVM spec
allows implementors to make choices in how linking proceeds. An
implementor may choose to resolve symbolic references when they are
referenced. In that case, the exceptions would be thrown within Call at
the point where, for example, a DOMSource is instantiated. That would
be the best case scenario to handle. However, most JVMs do resolution
when the class is first referenced. In that case, the first time the
code did a new Call(), the JVM would throw the exception. That would be
a problem, but perhaps it could be addressed by moving the "optional"
code to a separate class that Call would instantiate and catch the
exception at that instantiation. That's great, as long as no one
implements a JVM that is so aggressive with resolution that it resolves
symbolic references when the class is loaded. I doubt anyone would do
such as thing, as this means that all explicitly referenced classes
would be loaded when the app starts, but it is the worst case scenario.
Ultimately, I used reflection rather than putting the new code in a
separate class because it is the first thing that came to mind and is
used elsewhere in Apache SOAP.
Scott Nichol
----- Original Message -----
From: "Pavel Ausianik" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 17, 2002 2:13 PM
Subject: RE: SAXParser ?
> Scott,
>
> Sorry, I don't understand how could we force user to upgrade their
xerces.
> On the runtime, your code will not work with xerces 1.x anyway, if the
> classes not available. However once we compiled soap library with
having
> xalan / cerses 2 in classpath we should be able to run soap lib
without it
> (Of cource we need to handle NoClassDefFoundError just like currently
other
> exceptions are handled (like ClassNotFoundException). So the only
limitation
> we add in this case is to have xml-apis.jar in path for compilation,
but
> not for runtime.
>
> However seems like no need for this. I did small performance testing
and it
> seems like with a way proposed (SAXSource -> DOMResult) the
performance is
> only getting worse!
> Here the code to prove (I added following before end of class
> org.apache.soap.rpc.Call class for simplicity testing)
>
>
> static TransformerFactory f = TransformerFactory.newInstance();
> Transformer trans;
>
> private Document parsePayload2(String payload) throws IOException,
> SAXException {
> InputSource input = new InputSource(new
StringReader(payload));
> if (true) {
> try {
> if (f == null)
> f = TransformerFactory.newInstance();
> // use one transformer, because DocumentBuilder is cached in
call
> too
> if (xdb == null)
> xdb = XMLParserUtils.getXMLDocBuilder();
>
> if (trans == null)
> trans = f.newTransformer();
>
> DOMResult result = new DOMResult();
> result.setNode(xdb.newDocument());
> SAXSource source = new SAXSource(input);
>
> // Transform from SAX source to DOM result
> trans.transform(source, result);
> // If all has worked, we return here; for exceptions,
> // we fall through to the DOM parser.
> return (Document) result.getNode();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
>
>
> // if the DOM parser hasn't been created yet, do it now
> if (xdb == null)
> xdb = XMLParserUtils.getXMLDocBuilder();
> return xdb.parse(input);
> }
>
>
>
> public static void main(String[] args)
> {
> try {
> java.io.FileInputStream fis = new
> java.io.FileInputStream(args[0]);
> byte []bytes = new byte[fis.available()];
> fis.read(bytes);
> String str = new String(bytes);
> fis.close();
> Call call = new Call();
> int n=1000;
>
> call.setUseDocumentBuilder(false);
>
> long l1 = System.currentTimeMillis();
> for (int i=0; i<n; i++) {
> Node d = call.parsePayload(str).getFirstChild();
> if (i==0)
> System.out.println(d.toString());
> }
> long l2 = System.currentTimeMillis();
>
> call.setUseDocumentBuilder(true);
>
> for (int i=0; i<n; i++) {
> Node d = call.parsePayload(str).getFirstChild();
> if (i==0)
> System.out.println(d.toString());
> }
>
> long l3 = System.currentTimeMillis();
> for (int i=0; i<n; i++) {
> Node d = call.parsePayload2(str).getFirstChild();
> if (i==0)
> System.out.println(d.toString());
>
> }
> long l4 = System.currentTimeMillis();
>
> System.out.println("" + (l4-l3) + " " + (l3-l2) + " " +
(l2-l1));
> } catch (Exception e)
> {
> e.printStackTrace();
> }
> }
>
>
> I've tested with jre1.3.1, xalan 1.2.4, xerses 2.x. I've used copuple
of
> xmls, one of them around 15k (build.xml from soap distribution),
second 7k.
> Of cource with other engines result could be completely different. I
don't
> have an real SOAP envelope, but this should not be a problem, the
result
> should be quite the same.
> Results shows the same:
>
> 26624 14000 37467
>
> First time is for getting transformation using my function (some
tricks to
> improve transformatiom & caching for Factory, Transformer, etc.)
> Second is time for DOM implementation
> Third is current "SAX" implementation
>
> The second time is definetly better up to 3 times! than using
Transformation
> Using some trick with caching it is possible to get 50% off curretn
SAX
> implementation (I believe it is fair because DocumentBuilder is being
cached
> anyway), it it is still twice worse than DOM.
>
> Of cource it is not clean SAX Solution, but I agree that it is too
much
> efforts.
>
> BTW, before I did caching in my func, only do not having reflection
only I
> still was able to see more significant difference on results (around
3-5%,
> which I think still not bad)
>
> Best regards,
> Pave
>
>
> > -----Original Message-----
> > From: Scott Nichol [mailto:snicholnews@;scottnichol.com]
> > Sent: Thursday, October 17, 2002 8:28 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: SAXParser ?
> >
> >
> > Actually, I may be incorrect to say that users would have to upgrade
> > their XML parser. It is possible that something like Xalan would
work
> > with their existing parser, but then Xalan (or similar) would become
a
> > dependency for Apache SOAP.
> >
> > Scott Nichol
> >
> > ----- Original Message -----
> > From: "Scott Nichol" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, October 17, 2002 12:07 PM
> > Subject: Re: SAXParser ?
> >
> >
> > > If reflection were not used, we would have a dependency on a later
> > > version of JAXP, which would require many users to upgrade their
XML
> > > parser. In particular, most users seem to use Xerces 1.x. The
only
> > > JAXP classes provided by it are
> > >
> > > javax/xml/parsers/DocumentBuilder.class
> > > javax/xml/parsers/DocumentBuilderFactory.class
> > > javax/xml/parsers/FactoryConfigurationError.class
> > > javax/xml/parsers/ParserConfigurationException.class
> > > javax/xml/parsers/SAXParser.class
> > > javax/xml/parsers/SAXParserFactory.class
> > >
> > > As for reflection and performance, it may make a difference when
> > > handling very small payloads. When I added this patch, however, I
> > > inserted code to measure the time spent in each call.
> > Basically, all
> > > the time is spent in javax.xml.transform.Transformer#transform,
e.g.
> > if
> > > it takes 5 seconds to parse the payload, that method takes 4.99
> > seconds.
> > > The cost of reflection is miniscule compared to parsing
> > that requires
> > > seconds or minutes.
> > >
> > > Scott Nichol
> > >
> > > ----- Original Message -----
> > > From: "Pavel Ausianik" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Thursday, October 17, 2002 11:00 AM
> > > Subject: RE: SAXParser ?
> > >
> > >
> > > Scott,
> > >
> > > I'm not going to discuss the perfomance changes by switching to
SAX
> > > parsing
> > > with producing DOMResult - just don't know if it could be, but I'm
> > > interesting what is the primary reason for using reflection API
and
> > > Class.forName, instead of using classes directly - this actually
> > could
> > > be
> > > performance issue itself.
> > >
> > > Best regards,
> > > Pavel
> > >
> > > > -----Original Message-----
> > > > From: Scott Nichol [mailto:snicholnews@;scottnichol.com]
> > > > Sent: Thursday, October 17, 2002 5:19 PM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: SAXParser ?
> > > >
> > > >
> > > > In short, I would love to have a speedier, SAX-based Apache
> > > > SOAP, but I
> > > > don't know where the effort would come from to do the work.
> > > >
> > > > I don't know of any time that any developer(s) said Apache
> > > > SOAP would be
> > > > moving to using SAX, and I know of no plans to do so. A
> > significant
> > > > part of very early Axis development was refactoring
> > everything to be
> > > > driven by SAX. I doubt we have the cycles here to repeat that
> > effort
> > > > (although volunteers are always welcome!). As it stands, I
> > > > only expect
> > > > some of the smallest items on the TODO list to be
> > addressed because
> > of
> > > > the lack of developers. (Note that I would like to package
> > > > the current
> > > > code as a release and cannot even get a more experience
> > contributor
> > to
> > > > help me through the steps of doing that!).
> > > >
> > > > There is an option in the current code, based on a contribution
> > > >
(http://marc.theaimsgroup.com/?l=soap-dev&m=102571700230501&w=2),
> > that
> > > > allows you to specify whether you want messages parsed by a DOM
> > parser
> > > > or by a SAX parser with a transform to a DOM result. The
> > contributor
> > > > reported significant speed improvement, although the few tests I
> > have
> > > > run have not corroborated this.
> > > >
> > > > Scott Nichol
> > > >
> > > > ----- Original Message -----
> > > > From: "Leif Nilsson TACMa" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Thursday, October 17, 2002 6:49 AM
> > > > Subject: SAXParser ?
> > > >
> > > >
> > > > There has been discussions about using a SAX parser
> > instead of a DOM
> > > > parser.
> > > > What is the status on this ?
> > > >
> > > > Quoting Axis:
> > > > Speed. Axis uses SAX (event-based) parsing to acheive
> > significantly
> > > > greater
> > > > speed than earlier versions of Apache SOAP.
> > > >
> > > > /Leif Nilsson
> > > >
> > > >
> > > > Leif Nilsson
> > > > Software Engineer
> > > >
> > > > TAC AB
> > > > Jägershillgatan 18
> > > > SE-213 75 Malmö, Sweden
> > > > Direct +46 40 38 69 56
> > > > Fax +46 40 21 82 87
> > > > Mobile +46 46 299 89 56
> > > > www.tac-global.com
> > > >
> > > > This email is intended only for the use of the individual
> > or entity
> > to
> > > > whom
> > > > it is addressed. It may contain information that is privileged,
> > > > confidential
> > > > or otherwise protected from disclosure under applicable law.
> > > > If you have
> > > > received this transmission in error, please delete it
immediately
> > and
> > > > notify
> > > > me by mailing me.
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > <mailto:soap-dev-unsubscribe@;xml.apache.org>
> > > > For additional commands, e-mail:
> > <mailto:soap-dev-help@;xml.apache.org>
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > <mailto:soap-dev-unsubscribe@;xml.apache.org>
> > > > For additional commands, e-mail:
> > <mailto:soap-dev-help@;xml.apache.org>
> > > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> <mailto:soap-dev-unsubscribe@;xml.apache.org>
> > For additional commands, e-mail:
<mailto:soap-dev-help@;xml.apache.org>
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
<mailto:soap-dev-unsubscribe@;xml.apache.org>
> > For additional commands, e-mail:
<mailto:soap-dev-help@;xml.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <mailto:soap-dev-unsubscribe@;xml.apache.org>
> For additional commands, e-mail: <mailto:soap-dev-help@;xml.apache.org>
>
> --
> To unsubscribe, e-mail: <mailto:soap-dev-unsubscribe@;xml.apache.org>
> For additional commands, e-mail: <mailto:soap-dev-help@;xml.apache.org>
>
>
--
To unsubscribe, e-mail: <mailto:soap-dev-unsubscribe@;xml.apache.org>
For additional commands, e-mail: <mailto:soap-dev-help@;xml.apache.org>
