On Wed, Nov 18, 2009 at 11:52 AM, Paul Davis <paul.joseph.da...@gmail.com> wrote: > On Wed, Nov 18, 2009 at 12:58 PM, Mikeal Rogers <mikeal.rog...@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
