couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Increasing Spidermonkey version
Date Wed, 18 Nov 2009 19:52:13 GMT
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).

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/

Mime
View raw message