cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: AW: some XSLT benchmarks
Date Wed, 20 Feb 2002 13:20:31 GMT
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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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


Mime
View raw message