couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thanos Vassilakis <>
Subject Re: Erlang vs JavaScript
Date Sun, 18 Aug 2013 04:51:43 GMT
Build views performance gains:
Python 4-6 times faster + less memory
Erlang 7-9 times faster + much less memory. 

On Aug 16, 2013, at 18:54, Jan Lehnardt <> wrote:

> I think it is worth putting Jason’s and Jens’s viewpoints on a scale of “learning
to live with the pain” and “finding relief for the pain”, where “pain” is any of
View Build Time or View Index Time from Jason’s glossary.
> If living with the pain works for you, Jason’s point of view is very valuable because
all you need to is accept the current situation :)
> But I think it is also worth considering that there are scenarios where living with the
pain is just not a fun or viable thing to do and then finding relief for the pain is a good
> This thread started a fork on dev@ with concrete engineering suggestions on how to make
this a reality in CouchDB, so please join us there if you want to help out.
> Best
> Jan
> --
> On Aug 16, 2013, at 17:24 , Jason Smith <> wrote:
>> On Fri, Aug 16, 2013 at 10:16 PM, Jens Alfke <> wrote:
>>> On Aug 15, 2013, at 10:14 AM, Jason Smith <> wrote:
>>>> To restate my final sentence which you quoted: Accessing a view is an
>>> index
>>>> scan, it hardly matters what the total data size is; therefore after the
>>>> building period, all views are basically always instantly available.
>>> You’re missing my point, Jason. Introducing an arbitrary “building period”
>>> implies you don’t care about the latency between a database update and when
>>> it becomes visible in view queries. As I said, that may be allowable in
>>> some types of applications, but definitely not all. To repeat my example,
>>> an e-commerce customer is not going to tolerate any “building period”
>>> longer than a second or two in between their clicking “Add To Cart” and the
>>> item showing up in their cart.
>> I agree. But a hypothetical "Add to cart" would only be one or two document
>> updates. That will be reflected in a view query pretty quickly. The HTTP
>> overhead is probably still the majority of the time spent; updating the
>> view index to reflect the new cart will be negligible.
>> Do we agree there? It occurs to me that you and I may work in different
>> environments. Perhaps you are accustomed to much heavier update frequency
>> than I.
>> My own glossary:
>> View build time: Building the views the first time you push a new design
>> document into an existing database. Can take a very long time, but can be
>> done "offline."
>> View update time: The time it takes couch to update a view to reflect those
>> updates which happened since either the view build, or the view update
>> (whichever was more recent).
>> To me, view update time is regrettable but for most applications
>> (read-heavy) it is not much of a problem. View build time is not a concern
>> because you can run it at your leisure and "promote" it to the true
>> document ID using COPY. In most situations, native views solve a
>> non-problem (although I've cited a few cromulent exceptions.)

View raw message