On Wed, Aug 14, 2013 at 11:50 PM, Jens Alfke <j...@couchbase.com> wrote: > On Aug 14, 2013, at 10:02 AM, Alexander Shorin <kxe...@gmail.com> wrote: > >> Erlang server bypassed stdio interface communication and addtional >> JSON decode/encode roundtrip, so it is faster than JS at some point. > > Yeah — the ironic thing is that state-of-the-art JS runtimes are probably > faster than Erlang* these days, but JS views are still going to be slower > because (a) they run in a separate process, and (b) the docs have to be > translated from Erlang terms into JS objects. My experience from working > inter-language bridges is that parameter marshaling is generally a > performance killer.
I believe that views can be processed in parallel to speed up indexing, but this will be trade-off between speed and overall server performance (easy to hit OOM state with big docs). Also, this will requires communication protocol changing and Samuel's already made a proposal about: https://issues.apache.org/jira/browse/COUCHDB-1743 https://docs.google.com/document/d/1JtfvCpNB9pRQyLhS5KkkEdJ-ghSCv89xnw5HDMTCsp8/edit But I agree with your last sentence. However, it's also tradeoff between flexibility and performance (; > * Not intending to start a language-performance flame war! But Erlang’s > interpreter is quite primitive by today’s standards: it doesn’t even have a > JIT. Offtopic joke: even PHP has JIT and dies after user request processing for years before Erlang (: -- ,,,^..^,,,
