Subj : Re: JavaScript execution speed
To   : Shanti Rao
From : Brendan Eich
Date : Fri Jan 28 2005 10:37 am

Shanti Rao wrote:
> Hi Brendan,
> 
> What's a fair benchmark to compare processing speed between JavaScript 
> and Perl? Perl is heavily optimized for string manipulations, of course. 
> What is SpiderMonkey designed to do quickly?


SpiderMonkey was originally designed for flexibility, not speed -- 
specifically the ability to reflect a "peer object system" such as the 
DOM implemented with native C data structures, without adding a lot of 
overhead, while still retaining the ability to do magic getters, 
setters, resolvers, etc.

SpiderMonkey has been optimized in many ways since the old days: 
cost-free object locking (see bug 
https://bugzilla.mozilla.org/show_bug.cgi?id=54743), string 
concatenation that scales with realloc 
(https://bugzilla.mozilla.org/show_bug.cgi?id=56940, see below for more 
on this one), etc.

SpiderMonkey is general-purpose, it was not designed to be especially 
fast at null-function calls, etc.  More emphasis went into flexibility 
and robustness over time (even recently, with the tail-recursion elim 
and Deutsch-Schorr-Waite GC-marking work that Igor and I did in 
https://bugzilla.mozilla.org/show_bug.cgi?id=203278).

Recent posts show us competing well with Rhino on a JITed JVM.  The 
future demands on the engine are likely to focus on these areas:

- Better native debugger integration, especially with Visual Studio.
- Better memory performance, automated GC scheduling, incremental or 
smoother GC.
- Static types for JS2/ES4 and the ability to find bugs with 
higher-level static analysis (not buffer overruns, more likely chrome 
depending on content and similar "data tainting" bugs).


> I notice that SM tends to slow down as its memory pool fills up, and 
> regular JS_GC() calls are required. What are the triggers for automatic 
> GC? Can I make scripts run faster by using a smaller arena?


The only automatic GC is when the nominal number of live GC-things hits 
the per-runtime GC-thing-byte limit you passed to JS_NewRuntime.  It has 
always been the case that you don't want to wait till then -- that's a 
safety backstop.  You should call GC regularly from a background thread 
(if you are using JS_THREADSAFE), and from the branch callback every 2^n 
for some n >> 10.

/be

.