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 <[EMAIL PROTECTED]> 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. > <[EMAIL PROTECTED]> > Friedrich Nietzsche > -------------------------------------------------------------------- __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
