It's impressive that this is cutting the numbers by half or so. If this is validated, I hope CouchDB integrates it to make the whole system much faster.
So far Windows doesn't seem to be getting the same boost, so we'll see how things shake out. Though I'm more excited to hack in some other code I've already written which will avoid the JSON conversions all together.
What's the point of this, exactly? You get Javascript interpreters that Erlang can talk to. Is the point simply to have a more widely known language as the 'scripting language' for the system? Because otherwise it would just make more sense to not bother, or perhaps even to use something like node.js directly and cut out the Erlang middle-man. But I admittedly know little about the situation, so perhaps someone can shed more light on it.
The reason we use an embedded scripting environment is so that the control can be handled by Erlang. Its quite true that we could have an external system doing Map/Reduce a la CouchDB-Lucene but that would just increase the pain point, plus make things even harder to move between systems due to configuration overhead etc.
Though the point of this post was mostly to play with the new erlang_js package as well as try and determine what cost is associated with the stdio communication channel used by the current view generation model.
4 comments
[ 3.7 ms ] story [ 14.8 ms ] threadThough the point of this post was mostly to play with the new erlang_js package as well as try and determine what cost is associated with the stdio communication channel used by the current view generation model.