On Fri, Aug 16, 2013 at 11:05 AM, Volker Mische <volker.mis...@gmail.com>wrote:
> On 08/15/2013 11:53 AM, Benoit Chesneau wrote: > > On Thu, Aug 15, 2013 at 11:38 AM, Jan Lehnardt <j...@apache.org> wrote: > > > >> > >> On Aug 15, 2013, at 10:09 , Robert Newson <rnew...@apache.org> 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’d love for someone to pick this up and give CouchDB, say, a > ./configure > >> --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’s > reading > >> this thread), but we should look into that and get us “native JS > views”, 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. > > I think the ultimate goal should be to be as little > conversion/serialisation as possible, hence no conversion to Erlang > Terms at all. > > Input as string > Parsing to get ID > Store as string > > Send to JS as string > Process with JS > Store as string > > Cheers, > Volker > > > I agree, (modulo the fact that I would replace a string by a binary ;) but that would be only possible if we extract the metadata (_id, _rev) from the JSON so couchdb wouldn't have to decode the JSON to get them. Streaming json would also allows that but since there is no guaranty in the properties order of a JSON it would be less efficient. - benoit
