"Jacek R. Ambroziak" wrote:
>
> Stefano,
>
> A new xmdrivers.jar is attached with an updated drived for XSLTC.
> You can now run your tests again.
Ok, ran the tests on my laptop, same hardware/software/condition as
before.
Results:
Xalan 2.3 XSLTC
---------------
Sun 1.3.1 [1] 118,09
Sun 1.3.1 [2] 257,73
Sun 1.3.1 [3] 390,13
Sun 1.4.0 [3] 353,04
IBM 1.3.0 [3] 345,93
XT
--
Sun 1.3.1 [1] 241,52
Sun 1.3.1 [2] 205,10
Sun 1.3.1 [3] 202,33
Sun 1.4.0 [3] 193,85
IBM 1.3.0 [3] 202,48
MSXML 3.0
---------
Sun 1.3.1 [1] 317,67
Sun 1.3.1 [2] 241,40
Sun 1.3.1 [3] 222,21
IBM 1.3.0 [3] 221,57
Sun 1.4.0 [3] 221,67
NOTES:
[1] all tests are run
[2] all tests but dbonerow (XSLTC is *very* slow on this, about 10 times
slower than XT)
[3] all tests but dbonerow, decoy, number, patterns
The third test is somewhat 'XSLTC-oriented' since I removed the tests
where it appears to be unreasonably slower (dbonerow, decoy and
patterns) and the one that triggers an exception (number) [please, guys,
fix this! I can provide stacktraces if you want]
COMMENTS:
---------
XSLTC is *fast*!!! It's even faster than native code!!!!!
I also tried to see if the test (running in java) was impacting the
native performance but the three tests on the different JVMs show that
the native code has always the same performance.
MSXML gains a lot in dbonerow (10 secs vs. 200 secs, a really huge
difference! but I think this is a synchronization issue since the CPU is
not going at full speed, or could be a Java I/O problem since it's
working on the biggest file)
Final result:
-------------
All these processors aren't exactly top class as far as compliance goes.
If you want a compliant processor use Xalan or Saxon, no way out.
But if you want to run *fast* and you don't need to stress every
function of XSLT, but perform normal stylesheets (like normally done in
cocoon, since some of the XSLT functionality if factored out in other
places), XSLTC is *without*any*doubt* the way to go.
Interesting enough: Java 1.3 is faster than Java 1.4 (all tests were
done with client JVM, since the tests aren't long enough to benefit from
the hotspot server VM) and faster than IBM (which is normally 10% faster
than SUN 1.3 in almost anything).
I think this could be due to the hand-written java assembly code that
XSLTC generates. In fact, no decompiler is able to decompile a translet
since no javac pattern is recognized... I assume they make extensive use
of direct jumping (which is prohibited in java since 'goto' is reserved
but not used, while is allowed at the bytecode level. Too bad I don't
have time to jump into their code, but should be fun for an old assembly
freak like me :) finally able to tune the JVM bytecode by hand :)
Seriously: hand-optimized java bytecode it's a dangerous approach since
every JVM implementation is different.
Ideal should for the XSLTC engine to recognize the JVM it runs in (via
system properties) and tune the generated bytecode on the running JVM. I
assume this could give some 20/30% more speed improvement, but it's a
potentially harmful thing to do since it might duplicate code and
requires *lots* of guesses on how the JVM works internally.
Anyway, seriously, XSLTC *is* a solution to the XSLT bottleneck problem.
Now: only one thing to add: let's make it work on Cocoon.
Xalan-guys, please, can you give us a hand there?
--
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]
