Stefano, A new xmdrivers.jar is attached with an updated drived for XSLTC. You can now run your tests again.
You'll need a bunch of jars in "runxsltmark" scripts:
XSLTCDriver)
CLASSPATH=$WORKDIR/third-party/xalan-j/bin/BCEL.jar
CLASSPATH=$WORKDIR/third-party/xalan-j/bin/xsltc.jar:$CLASSPATH
CLASSPATH=$WORKDIR/third-party/xalan-j/bin/java_cup.jar:$CLASSPATH
CLASSPATH=$WORKDIR/third-party/xalan-j/bin/JLex.jar:$CLASSPATH
CLASSPATH=$WORKDIR/third-party/xalan-j/bin/regexp.jar:$CLASSPATH
CLASSPATH=$WORKDIR/third-party/xalan-j/bin/runtime.jar:$CLASSPATH
;;
(regexp is from jakarta)
You may also need to modify default.conf in 'testcases' dir.
For instance I have disabled 'dbonerow' which a very long time for translets
(and I don't yet know why).
If you have any trouble with running the benchmark send me email.
--Jacek
On Monday 18 February 2002 10:22 am, [EMAIL PROTECTED] wrote:
> (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:
> <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]]
> Gesendet: Sonntag, 17. Februar 2002 23:21
> An: 'Stefano Mazzocchi '; 'Apache Cocoon '
> Cc: 'Apache Xalan '
> Betreff: RE: some XSLT benchmarks
>
>
>
> Thесе benchmarkс 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.
xmdrivers.jar
Description: application/jar
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
