Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jchris@gmail.com designates
 209.85.216.202 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type;
        b=waDeKT2MKqQDMGN0DPqvewZ5joUqfD0f+3Z4oGXrVh/DLcjYFdVOF9ZMF6Sn0Fd9eQ
         DRJp3cPGw+pmrTWBYKo/UTHqxUCfzFy/fzP/fe1nj038scPuYY68U03hCB1DSmnU0FaY
         JqTc5HjJ+wVoGbczzddZ3MU2jl8cYw7PG3tpo=
MIME-Version: 1.0
Sender: jchris@gmail.com
In-Reply-To: <e2111bbb0911181152i77125bccw8ed2f930ee0c0b2b@mail.gmail.com>
References: <30747dfa0911180958w5a28f4a5j2dd7b3b3c2062660@mail.gmail.com>
	 <e2111bbb0911181152i77125bccw8ed2f930ee0c0b2b@mail.gmail.com>
Date: Wed, 18 Nov 2009 13:04:32 -0800
Message-ID: <e282921e0911181304n11d0379dx3f5f927e5148b68d@mail.gmail.com>
Subject: Re: Increasing Spidermonkey version
From: Chris Anderson <jchris@apache.org>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 18, 2009 at 11:52 AM, Paul Davis
<paul.joseph.davis@gmail.com> wrote:
> On Wed, Nov 18, 2009 at 12:58 PM, Mikeal Rogers <mikeal.rogers@gmail.com> wrote:
>> CouchDB currently uses Spidermonkey 1.7 as it's javascript interpreter.
>>
>> 1.7 was released in 2007. 1.8.5 is the current version number used in trunk,
>> anything 1.8.1 should have tracing support and should be much improved in
>> terms of performance.
>>
>> 1.8.x also has a lot of new JavaScript features that would be incredibly
>> useful in views (array comprehensions would be a godsend).
>>
>> Mozilla also has a native JSON parser written in C which is something like
>> 2.7 times faster than eval.
>>
>> http://blog.mozilla.com/webdev/2009/02/12/native-json-in-firefox-31/
>>
>> I'm wondering what barriers, if any, there are to increasing the required
>> Spidermonkey version. I've also been told that there are some issues with
>> using the C based JSON parser because of the way undefined is encoded in
>> arrays and would like a little more clarity on what work would need to
>> happen to get that in.
>>
>> My biggest concern is that as more view servers are implemented in other
>> languages javascript becomes the "slow" option, which seems ridiculous given
>> the performance leapfrogging in recent years between js interpreters. In my
>> tests the biggest speed differential appears to be JSON parsing:
>>
>> http://www.mikealrogers.com/archives/673
>>
>> -Mikeal
>>
>
> Mikeal,
>
> Excellent break down in the blog post and I agree 100%. The biggest
> place that the JS view server could currently benefit is in the JSON
> parsing. The C parser in 1.8.1 does have a measurable difference [1].
> You're also correct in point out that the new spec is slightly
> different than the json.js behavior we currently have.
>
> John Resig points out [2] that json2.js gives the ECMA5 behavior and
> transparently falls back to the native implementation when it exists.
> In terms of upgrade path, if we replace json.js with json2.js and fix
> the resulting errors we should be able to use any version of
> Spidermonkey from 1.7 onwards. Currently, the build system should
> handle each version just fine, so it should just be a matter of fixing
> the slightly different json2 behavior (which only affects two or three
> tests if memory serves).

It'd be happy to make the switch to the newer spidermonkey. I don't
think we need to sweat the 'undefined' handling details.

When we chose JavaScript, it was because it is ubiquitous and simple.
We've got some code that expects a particular handling of 'undefined',
but if the language is changing (native JSON support for a different
handling of 'undefined') I think we should change with the language.
It's in CouchDB's interest to follow the prevailing wind here.

Does anyone know the status of native JSON support on other browsers,
and how 'undefined' is handled?

Chris

>
> Also, I'm hesitant to upgrade our minimum version requirement. The SM
> release story is less than awesome. The only tarballs at [3] are for
> 1.7 and 1.8.0 which is a weird limbo version between 1.7 and 1.8.1.
> Not to mention its got a whacky build system that requires a specific
> version of Autoconf. So, yeah, making the upgrades progressive would
> be awesome.
>
> Oh, heh, looks like I said the same thing before. I would rephrase the
> "shows up in package managers" now to "has a release of some sort". At
> the very least having something that I can point people at and say
> "That version" would be good.
>
> Paul Davis
>
> [1] http://www.davispj.com/2009/05/18/couchdb-timings.html
> [2] http://ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/
> [3] http://ftp.mozilla.org/pub/mozilla.org/js/
>


-- 
Chris Anderson
http://jchrisa.net
http://couch.io