EMAIL PROTECTED],
(bcc: Scott Boag/Cambridge/IBM)
Subject: Re: AW: some XSLT benchmarks
[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
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
> 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 i
[EMAIL PROTECTED], Santiago
Pericas <[EMAIL PROTECTED]>
02/19/2002 11:22 Subject: Re: AW: some XSLT benchmarks
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
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
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.
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 d
MORAVEK Peter wrote:
>
> > Results:
> > Xalan 2.3 XSLTC
> > XT
> > MSXML 3.0
>
> And what about SAXON and MSXML 4.0 ? How are the results of the benchmarks
> with these two transformers ?
Saxon was way slower (around 100, check my previous post on the matter)
I couldn't test MSXML 4.0 because
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 '
> Results:
> Xalan 2.3 XSLTC
> XT
> MSXML 3.0
And what about SAXON and MSXML 4.0 ? How are the results of the benchmarks
with these two transformers ?
Thanks
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional co
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
--- 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
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
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
"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
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
>
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
>
Jörn Heid
n.de>cc: (bcc: Scott
Boag/Cambridge/IBM)
Electric XML is not SAX or DOM based. For that it won't make sense I think.
But XSLTC will be a nice alternative. But can you use XSLTC with SAX Events?
-Ursprüngliche Nachricht-
Von: Ivanov, Ivelin [mailto:[EMAIL PROTECTED]]
Gesendet: Sonntag, 17. Februar 2002 23:21
An: 'Stefano Mazzocch
21 matches
Mail list logo