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]
