From dev-return-24955-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Mon Jan 28 07:46:07 2013 Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6DF0DE004 for ; Mon, 28 Jan 2013 07:46:07 +0000 (UTC) Received: (qmail 94028 invoked by uid 500); 28 Jan 2013 07:46:07 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 93705 invoked by uid 500); 28 Jan 2013 07:46:06 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 93659 invoked by uid 99); 28 Jan 2013 07:46:05 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Jan 2013 07:46:05 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.214.176 as permitted sender) Received: from [209.85.214.176] (HELO mail-ob0-f176.google.com) (209.85.214.176) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Jan 2013 07:45:58 +0000 Received: by mail-ob0-f176.google.com with SMTP id v19so2452820obq.21 for ; Sun, 27 Jan 2013 23:45:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=vohEHg4Kwm90v6xwt3UlLYOSJU0rvrQm6zoemDi7uyA=; b=my0n6aP7kN3oOPwlzT++vEEC420pINazDSeJ1zJTx03zUmXik4jk7Q5h8Lh0ZV2r8b erzTofkpFURug34ke/FnQw7/R93yiwUlf7wDlpj7MAynvGSrGrjnOU6tY2Nl9EQX7zex bs87SvulnyfbdLbMhF0PIx7dhnK0ChwoHFeTe68FSuJeJ6y7sovn4aVhXVKBio1jSQSW w7Gx6HhLukobvefAPRLMrbtQZ3ttWbC1rX8kRqw8v0aPLdB2JFTfJUvNTTd6zXR57z5Z Wgu47150nJctw4YEAGbIxYSb7+pQo+MJ5emnajDEZ+XhNcLi5esbz8jLxZForw9uJsrQ K7fg== X-Received: by 10.60.31.68 with SMTP id y4mr10620801oeh.121.1359359137780; Sun, 27 Jan 2013 23:45:37 -0800 (PST) Received: from [192.168.1.250] (ip70-171-164-22.om.om.cox.net. [70.171.164.22]) by mx.google.com with ESMTPS id b6sm7479660oee.3.2013.01.27.23.45.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jan 2013 23:45:36 -0800 (PST) References: <81DDAD4E-8509-4029-A788-64DB2DF19C02@apache.org> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: Cc: CouchDB Developers X-Mailer: iPad Mail (9B206) From: "Paul J. Davis" Subject: Re: All The Numbers -- View Engine Performance Benchmarks Date: Mon, 28 Jan 2013 01:45:36 -0600 To: "dev@couchdb.apache.org" X-Virus-Checked: Checked by ClamAV on apache.org I tried this a long time ago with the binary to JS code in C. It didn't make= for a huge improvement in total speed. On Jan 27, 2013, at 11:37 PM, Jason Smith wrote: > Hey, Jan. This is a totally random and hypothetical idea: >=20 > Do you think there would be any speedup to use term_to_binary() and > binary_to_term() instead of encoding through JSON? The view server would o= f > course need to support that codec. I have already implemented encoding in > erlang.js: https://github.com/iriscouch/erlang.js >=20 > My suspicion is that there would be minor or zero speedup. The Erlang side= > would get faster (term_to_binary is faster) but the JS side would get > slower (custom decoding rather than JSON.parse()). The JS VM is slightly > faster so the total change would reflect that. >=20 > But I thought I'd share the idea. >=20 > On Sun, Jan 27, 2013 at 12:50 PM, Jan Lehnardt wrote: >=20 >>=20 >> On Jan 27, 2013, at 13:22 , Alexander Shorin wrote: >>=20 >>> On Sun, Jan 27, 2013 at 3:55 PM, Jason Smith wrote: >>>>=20 >>>> * Very little difference in different implementations (because stdio is= >> the >>>> bottleneck) >>>=20 >>> Why stdio is a bottleneck? I'm interesting underlay reasons. >>=20 >> It is actually not the the stdio, but the serialisation form erlang-terms= >> to JSON to JS Objects to JSON to erlang terms. >>=20 >> Cheers >> Jan >> -- >>=20 >>=20 >>>=20 >>> As for my experience, the protocol design doesn't allows view and >>> query servers works faster as they can. For example, we have 50 ddocs >>> with validate functions. For each document save there would be >>> executed from 100 commands (50 resets + 50 ddoc validate_doc_update >>> calls) till 150 commands (+ddocs caches), while it's possible to >>> process them in bulk mode. >>>=20 >>> -- >>> ,,,^..^,,, >>=20 >>=20 >=20 >=20 > --=20 > Iris Couch