cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacek Ambroziak <jacek_ambroz...@yahoo.com>
Subject Re: AW: some XSLT benchmarks
Date Wed, 20 Feb 2002 04:16:03 GMT
Stefano,

that is cool!  Except for the mysterious 'dbonerow'. I
will attempt to fix it
an in general I am going continue to follow my
original vision
to make XSLTC a good technology for people to actually
use.

You are right, there are multiple 'goto's' in the
generated bytecodes
(although the bytecodes are not hand-optimized, right?
:-)
but automatically generated), so that translets do not
correspond
to any valid Java program.  Decompiling to FORTRAN
would be a different
thing :-)  This is one of the reasons why I chose to
generate bytecodes
directly instead of Java code (which would make
compilation longer, too).

As to you other suggestions... I think a lot of time
is spent *around*
transformation, ie. first building the (special) DOM,
and then
serializing (or otherwise using) transformation
output.
In other words, even if transformation would take
exactly 0 ms,
we'd see a lot of time going to broadly conceived of
input/output.
That's why translets shine when the same DOM objects
can be reused,
perhaps to generate different 'views' of a document,
eg. personalize)
-- at least building-the-DOM part is factored out.

Next I'd like to address 'dbonerow'; the benchmark
kills XSLTC  :-(
so that it ends the race last w/ 10 iterations of the
test.

--Jacek


--- Stefano Mazzocchi <stefano@apache.org> wrote:
> "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.
> <stefano@apache.org>                            
> Friedrich Nietzsche
> --------------------------------------------------------------------

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com

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


Mime
View raw message