AW: AW: some XSLT benchmarks

2002-02-21 Thread Seiler, Christian
> Please, Stefano. No offense taken, and I was not trying to > be defensive. > I agree 100% that XSLTC is an ideal choice for high performance > applications. If I didn't think so it wouldn't have been > brought into the > Xalan project. We put a lot of our hopes into XSLTC. I > agree 100%

Re: AW: some XSLT benchmarks

2002-02-21 Thread scott_boag
EMAIL PROTECTED], (bcc: Scott Boag/Cambridge/IBM) Subject: Re: AW: some XSLT benchmarks

Re: AW: some XSLT benchmarks

2002-02-20 Thread Stefano Mazzocchi
[EMAIL PROTECTED] wrote: > > Yes, I agree with Berin on this, though I also agree with Jacek that > there's little reason that it should not scale well. > > Another factor is "incremental" output, which Xalan interpretive does a lot > of work to do well (and tends to take penalty for), and XSLTC

Re: AW: some XSLT benchmarks

2002-02-20 Thread Berin Loritsch
Santiago Pericas wrote: >> 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

Re: AW: some XSLT benchmarks

2002-02-20 Thread Jacek Ambroziak
You guys may find another data point interesting... (I am using Sun's newest 1.4 on Linux) I reran the test with '-verbosegc' flag gathering GC info into files. and then counted Full garbage collections grep Full gcXSLTC | wc -l grep Full gcXT| wc -l and so on. The results: XSLTC21 X

Re: AW: some XSLT benchmarks

2002-02-20 Thread Stefano Mazzocchi
Santiago Pericas wrote: > > > 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

Re: AW: some XSLT benchmarks

2002-02-20 Thread Stefano Mazzocchi
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 '

Re: AW: some XSLT benchmarks

2002-02-20 Thread scott_boag
[EMAIL PROTECTED], Santiago Pericas <[EMAIL PROTECTED]> 02/19/2002 11:22 Subject: Re: AW: some XSLT benchmarks

AW: AW: some XSLT benchmarks

2002-02-20 Thread Seiler, Christian
> 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 > requi

Re: AW: some XSLT benchmarks

2002-02-19 Thread Berin Loritsch
Jacek Ambroziak wrote: > --- Berin Loritsch <[EMAIL PROTECTED]> wrote: > >>Stefano Mazzocchi wrote: >> >>>"Jacek R. Ambroziak" wrote: >>> >>> > >>>Anyway, seriously, XSLTC *is* a solution to the >>> >>XSLT bottleneck problem. >> > >>My question is this: how does it _scale_. >> >> > >>I would

Re: AW: some XSLT benchmarks

2002-02-19 Thread Jacek Ambroziak
--- Berin Loritsch <[EMAIL PROTECTED]> wrote: > Stefano Mazzocchi wrote: > > "Jacek R. Ambroziak" wrote: > > > > Anyway, seriously, XSLTC *is* a solution to the > XSLT bottleneck problem. > > > My question is this: how does it _scale_. > > I would like to see the *same* tests with 100 > th

Re: AW: some XSLT benchmarks

2002-02-19 Thread Berin Loritsch
Stefano Mazzocchi wrote: > "Jacek R. Ambroziak" wrote: > > 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 harmfu

Re: AW: some XSLT benchmarks

2002-02-19 Thread Jacek Ambroziak
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 by

Re: AW: some XSLT benchmarks

2002-02-19 Thread Stefano Mazzocchi
"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

Re: AW: some XSLT benchmarks

2002-02-18 Thread Davanum Srinivas
Scott, FYI, Right now the Translets are unusable for C2 :( http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6312 Thanks, dims --- [EMAIL PROTECTED] wrote: > > 5) i haven't tested Xalan Translets, which, along with compiled XML > > might be *the* way to go for Cocoon production environments >

Re: AW: some XSLT benchmarks

2002-02-18 Thread Jacek R. Ambroziak
If you would like to discuss the technical > details of what's going on, I would be glad to. The issues aren't simple, > though the results and the perception of the results are. > > -scott > > > > > > Jörn Heid >

Re: AW: some XSLT benchmarks

2002-02-18 Thread scott_boag
Jörn Heid n.de>cc: (bcc: Scott Boag/Cambridge/IBM)