cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From scott_b...@us.ibm.com
Subject Re: AW: some XSLT benchmarks
Date Mon, 18 Feb 2002 15:22:33 GMT

(cross posted to xalan-dev)

> But can you use XSLTC with SAX Events?

Yes.

Some quick responses to Stefano's note...

> 5) i haven't tested Xalan Translets, which, along with compiled XML
> might be *the* way to go for Cocoon production environments

Yes, I think so.  I'm surprised that people on the Cocoon side haven't done
more experimenting with Translets.

Remember that XSLTC now implements that jaxp.xml.transformer interface, so
you should be able to Run with them fairly easily.

> 2) XT is still spectacularly fast, even if abandoned a long time ago

But not XSLT 1.0 complient... the edge cases in the spec do indeed eat
cycles.

One thing I do is compile XT on the same compiler that Xalan is compiled
with, and use it with Xerces.  (Also, with SAXON, use it with Xerces).

> is still *way* faster than Xalan (twice as fast, normally)
> worries me very much.

Yes.  Believe me that I've spent a lot of time both with the DataPower
benchmarks and in JProbe.  Some of the difference is in the serializers (I
don't think Cocoon is using Xalan's serializers anyway), which I've been
working on.  Some of the difference is probably in source tree
construction.  Probably a major difference is in the instrumentation that
Xalan provides, and the state tracking that it does.  I'm working at
improving this particular issue by using derived classes when
instrumentation is needed.

Some other performance improvements that *haven't* been checked in yet or
are on a branch:
1) General reduction of state tracking
2) Reduction of redundant expressions (4x improvement on one of the Cocoon
files that Davinum gave us, but fairly little diff on DataPower
benchmarks).
3) Serialization improvements

A major issue with Xalan is the source tree representation, which is
currently the DTM.  XSLTC uses a format very similar to the DTM (the
current DTM is partly copied from XSLTC, with development ongoing Xalan
interpretive and compiled to use the same source tree).  Even SAXON has a
DTM-like source tree, originally copied from the Xalan notion (I'm pretty
sure).  But the DTM has some serious drawbacks too (subtree pruning is
hard, and array access in Java tends to be a bit slow).

> Flamesuit on, fire at need.

Not interested in flame wars.  If you would like to discuss the technical
details of what's going on, I would be glad to.  The issues aren't simple,
though the results and the perception of the results are.

-scott




                                                                                         
                                             
                      Jörn Heid                                                         
                                              
                      <heid@fh-heilbron        To:       <cocoon-dev@xml.apache.org>
                                                  
                      n.de>                    cc:       (bcc: Scott Boag/Cambridge/IBM)
                                              
                                               Subject:  AW: some XSLT benchmarks        
                                             
                      02/17/2002 06:25                                                   
                                             
                      PM                                                                 
                                             
                      Please respond to                                                  
                                             
                      cocoon-dev                                                         
                                             
                                                                                         
                                             
                                                                                         
                                             




Electric XML is not SAX or DOM based. For that it won't make sense I think.
But XSLTC will be a nice alternative. But can you use XSLTC with SAX
Events?

-----Urspr√ľngliche Nachricht-----
Von: Ivanov, Ivelin [mailto:Ivelin_Ivanov@bmc.com]
Gesendet: Sonntag, 17. Februar 2002 23:21
An: 'Stefano Mazzocchi '; 'Apache Cocoon '
Cc: 'Apache Xalan '
Betreff: RE: some XSLT benchmarks



Th&#1077;&#1089;&#1077; benchmark&#1089; make it clear that Xalan J is far
from the winner.
For completeness however, wouldn't it be fare to include XSLTC as well.
Also Electric XML is a fast free parser which should probably be taken into
account. http://www.themindelectric.com/products/xml/benchmarks.html


Regards,

Ivelin

-----Original Message-----
From: Stefano Mazzocchi
To: Apache Cocoon
Cc: Apache Xalan
Sent: 16.2.2002 a. 10:58
Subject: some XSLT benchmarks

[crossposting on xalan-dev since they might be interested in these
results]

I want to have numbers to know whether or not a native implementation of
an XSLT transformer for Cocoon would make sense, so I did some
benchmarks.

I used XSLTMark and rerun the test on my machine (old laptop, but
anyway), here are the results, I'll commment them below.

Hardware
========

 Sony VAIO PCG-F280
 Intel Pentium II 366 Mhz
 128 Mb RAM
 Microsoft Windows 2000 - Service Pack 3 [1]



Xalan-J (built into JDK 1.4, uses crimson)
-------

Sun 1.4.0 (client)  108,73

Xalan-J 2.3 + Xerces 2.0 (latest and greatest)
-------

IBM 1.3.0            74,80
Sun 1.3.1_02         56,45
Sun 1.4.0 (client)   55,11

Xalan-J 2.3 + Crimson
---------------------

IBM 1.3.0            85,27
Sun 1.4.0 (client)   76,02[2]

Xalan-J 2.2.0 + Xerces 1.4.4 (shipped with Cocoon 2.0.1)
------------------------------

IBM 1.3.0            85,27
Sun 1.3.1_02         61,08
Sun 1.4.0 (client)   57,10

Saxon 6.5.1
-----------

IBM 1.3.0           147,78
Sun 1.3.1_02        120,99
Sun 1.4.0 (client)  103,58
Sun 1.4.0 (server)   79,52

XT + XP
-------

IBM 1.3.0           251,62
Sun 1.3.1_02        244,64
Sun 1.4.0 (client)  229,44
Sun 1.4.0 (server)  171,26


MSXML
-----

(native)            322,95


FastXML (http://www.geocities/fastxml/)
---------------------------------------

(native)           1056,99[2]


NOTES:

[1] all programs in the tray bar or background were removed, ethernet
disconnected, and mouse left untouched during the runs.

[2] this was obtained by moving 'xalan.jar' into the
java_home/lib/endorsed
directory, but without moving 'xerces-impl.jar' so that the default SAX
handler is the one shipped with the JDK 1.4 (which is crimson).

[2] this processor is an half-baked win32-only version which was
optimized
by hand for the x86 architecture and had some parsing and compliance
errors
(XSLTMark reports 70% compliance, against 94% for MSXML and 100% for
saxon and
Xalan)

---------------------------------------------------------------------

A few things to note:

1) Xalan is slow. Sorry people, but almost every serious parser beats
Xalan in terms of pure throughtput. The fact that XT (abandoned by
years) is still *way* faster than Xalan (twice as fast, normally)
worries me very much.

WARNING: I've run the tests as the guys in XSLTMark wrote them, so it is
entirely possible they didn't use optimization tricks. If you Xalan
folks know some and want to rewrite the Xalan driver for XSLTMark, I'm
sure everyone here will appreciate that.

2) XT is still spectacularly fast, even if abandoned a long time ago (I
used the source from www.jclark.com not the ones from 4xt.org). Cocoon
will continue to ship it as long as Xalan can match its speed (and I
still can't imagine why it doesn't!)

3) Xerces 2.0 appears slower than Xerces 1.4.4, and crimson appears
faster than Xerces in almost every case.

4) MSXML is faster than XT, but it't not using a SAX interface, so, as
Berin suggested, connecting a native SAX handler might waste the benefit
of native speed thru the JNI connection since lots of methods must be
called.

I think Ovidiu is right saying that we should concentrate on having a
faster (lighter?) and even non-completely-compliant XSLT processor that
is focused on speed.

5) i haven't tested Xalan Translets, which, along with compiled XML
might be *the* way to go for Cocoon production environments: when you
need speed, you compile your XML files (so get rid of the parsing stage)
and compile the XSLT into translets (then we could easily wrap them and
make them cocoon transformers) and we could be ready to kick ass.... but
there was no XSLTMark driver for the Xalan translets (only for old Sun's
XSLTC) and I didn't have time to write one myself (hint hint).

6) the FastXML parser is real, but I think it's cheating: writing an
XSLT processor in assembly is a total waste of time, with the price of
development compared with the price of hardware. Anyway, I asked the
author (who now works for Microsoft.. guess why :) if she cared to open
source it and donate the code to us. I'll let you know if anything
happens here.

At the end: we need faster XSLT processing and I'm sorry but Xalan
doesn't seem to be leading the way as I would like it to do :/

Flamesuit on, fire at need.

--
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org







---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message