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 may have a
much harder time at.  On the other hand, especially given cacheing,
incrementality may not matter at all.  On the other hand, given Cocoon
pipelines, it may matter a lot.

(Hopefully, XSLTC can eventually be given incremental capabilities...
though certainly not at the expense of any performance).

I would like to eventually see much more sophisticated benchmarks than
XSLTMark, which I think only tells about 20% of the performance story.

-scott




                                                                                       
                                                
                      Berin Loritsch                                                   
                                                
                      <bloritsch@apache        To:       [EMAIL PROTECTED]     
                                                
                      .org>                    cc:       "Jacek R. Ambroziak" 
<[EMAIL PROTECTED]>, [EMAIL PROTECTED],   
                                                [EMAIL PROTECTED], Santiago 
Pericas <[EMAIL PROTECTED]>                         
                      02/19/2002 11:22         Subject:  Re: AW: some XSLT benchmarks  
                                                
                      PM                                                               
                                                
                      Please respond to                                                
                                                
                      xalan-dev                                                        
                                                
                                                                                       
                                                
                                                                                       
                                                




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 harmful thing to do since it might duplicate code and
> requires *lots* of guesses on how the JVM works internally.
>
> Anyway, seriously, XSLTC *is* a solution to the XSLT bottleneck problem.
>
> Now: only one thing to add: let's make it work on Cocoon.
>
> Xalan-guys, please, can you give us a hand there?


My question is this:  how does it _scale_.

For instance, The ECM is quite resonable with only a few threads, but in
a server environment where there can be as many as 150 or more
concurrent threads it slows down so badly it is unusable.  A fresh
approach reaping the benefits of the lessons of the ECM and Phoenix
proved that the new approach can handle the load *much* more gracefully.

I would like to see the *same* tests with 100 threads each performing
500 translations (yes they can have their own instance of the translet
in each thread as is necessary).  I would like to see that in comparison
to Xalan and Saxon.

That is the most important lesson we can learn.



----------------------------------------------------
Sign Up for NetZero Platinum Today
Only $9.95 per month!
http://my.netzero.net/s/signup?r=platinum&refcd=PT97





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to