cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@cup.hp.com>
Subject Re: Continuation-enabled Rhino status (was: Re: [vote] Starting 2.1-dev)
Date Wed, 10 Apr 2002 21:01:16 GMT
On Wed, 10 Apr 2002 11:30:11 -0800, Rob Jellinghaus <robj@unrealities.com> 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 <ovidiu@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message