No assumptions about JVMs have been made; in fact translets used to run faster on IBM's VMs (esp. 1.1.8) which was a bit embarassing for me as a Sun-er at the time.
I am sure translets can be further optimized but JVM tuning would be the last (if at all) place to look at, maybe except for small devices. --Jacek --- Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > Jacek Ambroziak wrote: > > > > 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. > > Cool. > > > You are right, there are multiple 'goto's' in the > > generated bytecodes > > (although the bytecodes are not hand-optimized, > right? > > :-) > > but automatically generated) > > yes, automatically generated, but the 'XSLT to > bytecode' patterns have > been manually crafted, right? and I'm pretty sure > that you guys crafted > them based on the assumption on how the underlying > JVM was going to > interpret them. Which shows why it is faster on the > Sun 1.3.1 JVM (but > this is just my hypotesis) > > My point was: it would be cool to implement a way > for the 'XSLT 2 > bytecode' patterns to be choosen based on the JVM > system that is > currently running (or using a configurations, for > those translets that > have to be deployed on platforms different from > where the translet > assembly takes place) > > >, 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). > > Yes, this is a very intriguing technology and I > think it would be a > valuable tool for speed-optimizing java code for > specific cases. > > > 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. > > Good point. > > > Next I'd like to address 'dbonerow'; the benchmark > > kills XSLTC :-( > > so that it ends the race last w/ 10 iterations of > the > > test. > > Please look also into the 'numbers' test that throws > an exception.... > also you might want to run the test to see why there > are some invalid > results out of the transformation (compliancy is > less than Xalan's) > > -- > 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