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. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. <[EMAIL PROTECTED]> Friedrich Nietzsche -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
