Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D9DA010766 for ; Thu, 15 Aug 2013 09:53:59 +0000 (UTC) Received: (qmail 88538 invoked by uid 500); 15 Aug 2013 09:53:59 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 88093 invoked by uid 500); 15 Aug 2013 09:53:59 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 88075 invoked by uid 99); 15 Aug 2013 09:53:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Aug 2013 09:53:58 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of bchesneau@gmail.com designates 209.85.192.177 as permitted sender) Received: from [209.85.192.177] (HELO mail-pd0-f177.google.com) (209.85.192.177) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Aug 2013 09:53:54 +0000 Received: by mail-pd0-f177.google.com with SMTP id y10so643097pdj.22 for ; Thu, 15 Aug 2013 02:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IC1Q/8PEI+iY1zry5WaY9Jolo5X1HhHiAPz5w+O5YGU=; b=MhDGJ94Swhva4M2FAWCYpi670fObUxNePuq+Lpzy88eqlZPn1BNb0Izg836xGV9u4q 9y8H3+t7/BJlLEeuk7JwZiiGWzoZc5kJXawUeVsLH/dbqYQOyUjy2RAtvlPKKndtg3MT 2qa2DLOn6FStYD06jcnHz8UPrm90LvCEbkRyaL01CWCkzkV60kRTVx3hZQ26wOg2OIWu 3FGBTOfVch7BEnFFmSOTe28Xi2eyluJGXRjUwxnOqNOeHhZ8Szy+4hFfuA8fcvKSpGAh jSA47bQrYiuZzIuir+Y0UkRKM56pS0NDhbrAQlWD3Wb2MwjKkK5C5ZisoVsOVDE+MaGj sHVA== MIME-Version: 1.0 X-Received: by 10.66.25.102 with SMTP id b6mr14405845pag.129.1376560413782; Thu, 15 Aug 2013 02:53:33 -0700 (PDT) Received: by 10.70.53.8 with HTTP; Thu, 15 Aug 2013 02:53:33 -0700 (PDT) In-Reply-To: <57E7BFC7-8B8E-4014-8569-B03F99B73E35@apache.org> References:

<57E7BFC7-8B8E-4014-8569-B03F99B73E35@apache.org> Date: Thu, 15 Aug 2013 11:53:33 +0200 Message-ID: Subject: Re: Erlang vs JavaScript From: Benoit Chesneau To: "dev@couchdb.apache.org" Cc: "user@couchdb.apache.org" Content-Type: multipart/alternative; boundary=bcaec52bed1f79bafb04e3f97260 X-Virus-Checked: Checked by ClamAV on apache.org --bcaec52bed1f79bafb04e3f97260 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Aug 15, 2013 at 11:38 AM, Jan Lehnardt wrote: > > On Aug 15, 2013, at 10:09 , Robert Newson wrote: > > > A big +1 to Jason's clarification of "erlang" vs "native". CouchDB > > could have shipped an erlang view server that worked in a separate > > process and had the stdio overhead, to combine the slowness of the > > protocol with the obtuseness of erlang. ;) > > > > Evaluating Javascript within the erlang VM process intrigues me, Jens, > > how is that done in your case? I've not previously found the assertion > > that V8 would be faster than SpiderMonkey for a view server compelling > > since the bottleneck is almost never in the code evaluation, but I do > > support CouchDB switching to it for the synergy effects of a closer > > binding with node.js, but if it's running in the same process, that > > would change (though I don't immediately see why the same couldn't be > > done for SpiderMonkey). Off the top of my head, I don't know a safe > > way to evaluate JS in the VM. A NIF-based approach would either be > > quite elaborate or would trip all the scheduling problems that > > long-running NIF's are now notorious for. > > > > At a step removed, the view server protocol itself seems like the > > thing to improve on, it feels like that's the principal bottleneck. > > The code is here: > https://github.com/couchbase/couchdb/tree/master/src/mapreduce > > I=92d love for someone to pick this up and give CouchDB, say, a ./configu= re > --enable-native-v8 option or a plugin that allows people to opt into the > speed improvements made there. :) > > The choice for V8 was made because of easier integration API and more > reliable releases as a standalone project, which I think was a smart move= . > > IIRC it relies on a change to CouchDB-y internals that has not made it > back from Couchbase to CouchDB (Filipe will know, but I doubt he=92s read= ing > this thread), but we should look into that and get us =93native JS views= =94, at > least as an option or plugin. > > CCing dev@. > > Jan > -- > > Well on the first hand nifs look like a good idea but can be very problematic: - when the view computation take time it would block the full vm scheduling. It can be mitigated using a pool of threads to execute the work asynchronously but then can create other problems like memory leaking etc. - nifs can't be upgraded easily during hot upgrade - when a nif crash, all the vm crash. (Note that we have the same problem when using a nif to decode/encode json, it only works well with medium sized documents) One other way to improve the js handling would be removing the main bottleneck ie the serialization-deserialization we do on each step. Not sure if it exists but feasible, why not passing erlang terms from erlang to js and js to erlang? So at the end the deserialization would happen only on the JS side ie instead of having get erlang term encode to json send to js decode json process encode json send json decode json to erlang term store we sould just have get erlang term send over STDIO decode erlang term to JS object process encode to erlang term send erlang term store Erlang serialization is also very optimised. Both solutions could co-exist, that may worh a try and benchmark each... - benoit --bcaec52bed1f79bafb04e3f97260--