From user-return-25244-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Sun Aug 18 04:53:05 2013
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 4251D1069A
for ; Sun, 18 Aug 2013 04:53:05 +0000 (UTC)
Received: (qmail 19608 invoked by uid 500); 18 Aug 2013 04:53:03 -0000
Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org
Received: (qmail 19125 invoked by uid 500); 18 Aug 2013 04:52:54 -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 19113 invoked by uid 99); 18 Aug 2013 04:52:51 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 18 Aug 2013 04:52:51 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
tests=MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of thanosv@gmail.com designates 209.85.215.181 as permitted sender)
Received: from [209.85.215.181] (HELO mail-ea0-f181.google.com) (209.85.215.181)
by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 18 Aug 2013 04:52:44 +0000
Received: by mail-ea0-f181.google.com with SMTP id d10so1706465eaj.12
for ; Sat, 17 Aug 2013 21:52:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=subject:references:from:content-type:in-reply-to:message-id:date:to
:content-transfer-encoding:mime-version;
bh=ODhhAX2K48FRZtFQuXc8r26vNulwD5zf8Yrg080Etag=;
b=GVpvCR/nwWsjeMp3P+IV8BSDTOg8cBCiHfSkVyTQD2qIivDYbsAb74gmwpfqtv7CxR
dmShPmZ+/tNWxbu0WusP/LnLmLBbiChlOlkNviSsbgB9gqjRcNKqRuLBXsYQWBAIYL2H
I15EFTmxHDAKR2F64Q9xF4VdfgLSRA5Ie/E7BzFo32HsFfx0J4d0x0Uq4S9yRfI2xc3w
L1y8KKAgh5Cx6MLro5Ku/GuPFKUgdqIMHq6XXTrYtbvTB/9nD7ICTZuUXBBJ1Y0InYPp
23oonPbMRMmReRgiPfxVayIWPJo2RIY1yYs5/By+sXacGC8+ZvgyHLy1JuHA93PHGqn7
4VmQ==
X-Received: by 10.15.91.3 with SMTP id r3mr11197376eez.4.1376801544163;
Sat, 17 Aug 2013 21:52:24 -0700 (PDT)
Received: from [10.10.241.68] (athedsl-4522605.home.otenet.gr. [94.71.238.117])
by mx.google.com with ESMTPSA id z12sm7868710eev.6.1969.12.31.16.00.00
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sat, 17 Aug 2013 21:52:23 -0700 (PDT)
Subject: Re: Erlang vs JavaScript
References: <33DF91AF-94FF-4205-A6A9-B99030A489DA@couchbase.com> <47F84BCE-BBA0-490B-AE1D-DC70382A1320@couchbase.com> <5FD58AC4-DC89-492C-9FC6-A4A101954022@apache.org>
From: Thanos Vassilakis
Content-Type: text/plain;
charset=utf-8
X-Mailer: iPhone Mail (9A405)
In-Reply-To: <5FD58AC4-DC89-492C-9FC6-A4A101954022@apache.org>
Message-Id: <605C317E-C7A4-4AE6-9CD0-B042E0F57473@gmail.com>
Date: Sun, 18 Aug 2013 07:51:43 +0300
To: "user@couchdb.apache.org"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
X-Virus-Checked: Checked by ClamAV on apache.org
Build views performance gains:
Python 4-6 times faster + less memory
Erlang 7-9 times faster + much less memory.=20
On Aug 16, 2013, at 18:54, Jan Lehnardt wrote:
> I think it is worth putting Jason=E2=80=99s and Jens=E2=80=99s viewpoints o=
n a scale of =E2=80=9Clearning to live with the pain=E2=80=9D and =E2=80=9Cf=
inding relief for the pain=E2=80=9D, where =E2=80=9Cpain=E2=80=9D is any of V=
iew Build Time or View Index Time from Jason=E2=80=99s glossary.
>=20
> If living with the pain works for you, Jason=E2=80=99s point of view is ve=
ry valuable because all you need to is accept the current situation :)
>=20
> But I think it is also worth considering that there are scenarios where li=
ving with the pain is just not a fun or viable thing to do and then finding r=
elief for the pain is a good strategy.
>=20
> This thread started a fork on dev@ with concrete engineering suggestions o=
n how to make this a reality in CouchDB, so please join us there if you want=
to help out.
>=20
> Best
> Jan
> --
>=20
>=20
> On Aug 16, 2013, at 17:24 , Jason Smith wrote:
>=20
>> On Fri, Aug 16, 2013 at 10:16 PM, Jens Alfke wrote:
>>=20
>>>=20
>>> On Aug 15, 2013, at 10:14 AM, Jason Smith wrote:
>>>=20
>>>> 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 th=
e
>>>> building period, all views are basically always instantly available.
>>>=20
>>> You=E2=80=99re missing my point, Jason. Introducing an arbitrary =E2=80=9C=
building period=E2=80=9D
>>> implies you don=E2=80=99t care about the latency between a database upda=
te 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 =E2=80=9Cbuilding pe=
riod=E2=80=9D
>>> longer than a second or two in between their clicking =E2=80=9CAdd To Ca=
rt=E2=80=9D and the
>>> item showing up in their cart.
>>>=20
>>=20
>> I agree. But a hypothetical "Add to cart" would only be one or two docume=
nt
>> 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.
>>=20
>> 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.
>>=20
>> My own glossary:
>>=20
>> 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."
>>=20
>> View update time: The time it takes couch to update a view to reflect tho=
se
>> updates which happened since either the view build, or the view update
>> (whichever was more recent).
>>=20
>> 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 concer=
n
>> 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.)
>=20