Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 10458 invoked by uid 500); 20 Feb 2002 15:18:38 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 10441 invoked from network); 20 Feb 2002 15:18:37 -0000 Message-ID: <20020220151839.56493.qmail@web14102.mail.yahoo.com> Date: Wed, 20 Feb 2002 07:18:39 -0800 (PST) From: Jacek Ambroziak Subject: Fwd: Re: AW: some XSLT benchmarks To: cocoon-dev@xml.apache.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1229789791-1014218319=:56450" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --0-1229789791-1014218319=:56450 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Note: forwarded message attached. __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com --0-1229789791-1014218319=:56450 Content-Type: message/rfc822 X-Apparently-To: jacek_ambroziak@yahoo.com via web14107.mail.yahoo.com; 20 Feb 2002 07:15:59 -0800 (PST) X-Track: 2: 40 Return-Path: Received: from daedalus.apache.org (HELO apache.org) (64.125.133.20) by mta574.mail.yahoo.com with SMTP; 20 Feb 2002 07:15:59 -0800 (PST) Received: (qmail 7445 invoked by uid 500); 20 Feb 2002 15:15:51 -0000 Mailing-List: contact xalan-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: xalan-dev@xml.apache.org Delivered-To: mailing list xalan-dev@xml.apache.org Received: (qmail 7432 invoked from network); 20 Feb 2002 15:15:51 -0000 Date: Wed, 20 Feb 2002 07:15:46 -0800 (PST) From: Jacek Ambroziak Subject: Re: AW: some XSLT benchmarks To: xalan-dev@xml.apache.org Cc: xalancocoon-dev@xml.apache.org, xsltc-team@east.sun.com In-Reply-To: <3C73A29F.F6FA3960@apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Content-Length: 1673 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 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. > > Friedrich Nietzsche > -------------------------------------------------------------------- > > __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com --0-1229789791-1014218319=:56450 Content-Type: text/plain; charset=us-ascii --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org --0-1229789791-1014218319=:56450--