On Wed, 10 Apr 2002 11:30:11 -0800, Rob Jellinghaus <[EMAIL PROTECTED]> wrote:
> At 10:29 AM 4/10/2002 -0700, Ovidiu Predescu wrote: > >Rhino has two ways of running JavaScript scripts. The first one is > >translating the script in a structure of internal objects, which are > >then "executed". The second approach, a lot faster that the first one, > >translates the JavaScript scripts in internal Java classes, which are > >compiled to bytecodes on-the-fly and executed as normal Java code. > > > >Adding support for continuations in the compiler mode is not possible, > >due to the impossibility to manipulate the Java stack frame. > > This places a lower bound on the speed of any continuation-based Cocoon web > application. > > I would steer clear of using a non-compilable technology in any > sufficiently large-scale web site. Hence, this ower bound on the flow > engine's speed may imply an upper bound on the scale of Cocoon deployments > using the continuation-based flow engine. > > It is also curious how this performance constraint is so at odds with > Cocoon's general predilection to compile everything whenever possible, for > maximum throughput. > > It pains me to say all this, as I think continuations are elegant as hell > and Ovidiu's work seems quite impressive, but I do not believe that > continuations will become efficiently implementable in the JVM (or in > JVM-based languages) anytime in the next few years. Hence, I do not think > that continuations should become the main focus of Cocoon's flow support, > if Cocoon has scalability as a primary design goal. I don't see why we should stay away from non-compilable technology. Perl, Python, PHP and lots of other interpreted languages out there are successfully used to drive very large Web sites. None of them compiles anything to C, they all interpret the scripts that describe the Web application. Some of these Web applications have tens of thousands of lines of code, all interpreted. I haven't noticed any problem accessing sites like Slashdot (Perl), Yahoo Maps! (Python), Yahoo Store! (Common Lisp), and many others. We don't need to have continuations in the JVM to make use of them. Rhino JavaScript is quite fast as an interpreter even in interpreted mode. And remember, we use it only to drive the flow of pages, not to implement the whole application in it (although it is definitely possible to do it). If used carefully the continuations based approach to flow control should not add any noticeable overhead to an application. As a side note, last time I checked the speed and scalability of the interpreted sitemap, I didn't notice any difference from the compiled one. What I gain though by using it, is much more than speed: productivity. I don't have to wait forever until the sitemap is compiled. I'm a big fan of interpreted languages, I think they can speed up tremendously the development time. And most of the time, you don't give up any speed or scalability at deployment time because of that. The edit-compile-link model just sucks compared to what you do with an interpreter. Regards, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
