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