From cc2549b16679eea7a0b84c78b0003a5953f11bb3 Mon Sep 17 00:00:00 2001 From: Justus Winter <4winter@informatik.uni-hamburg.de> Date: Tue, 21 Feb 2012 17:15:09 +0000 Subject: [PATCH] Re: nomuch_addresses.py --- 53/710cbeaf8fe1280f5d074191b033d3e4514954 | 92 +++++++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 53/710cbeaf8fe1280f5d074191b033d3e4514954 diff --git a/53/710cbeaf8fe1280f5d074191b033d3e4514954 b/53/710cbeaf8fe1280f5d074191b033d3e4514954 new file mode 100644 index 000000000..f6e009cf9 --- /dev/null +++ b/53/710cbeaf8fe1280f5d074191b033d3e4514954 @@ -0,0 +1,92 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 1D203431FC2 + for ; Tue, 21 Feb 2012 01:15:25 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Date" +X-Spam-Flag: NO +X-Spam-Score: 0.432 +X-Spam-Level: +X-Spam-Status: No, score=0.432 tagged_above=-999 required=5 + tests=[INVALID_DATE=0.432] autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 4s1K-+oysRRY for ; + Tue, 21 Feb 2012 01:15:21 -0800 (PST) +Received: from mail.cryptobitch.de (cryptobitch.de [88.198.7.68]) + (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id 61A49431FAF + for ; Tue, 21 Feb 2012 01:15:21 -0800 (PST) +Received: from mail.jade-hamburg.de (unknown [85.183.11.228]) + (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) + (No client certificate requested) + by mail.cryptobitch.de (Postfix) with ESMTPSA id DCE7953122A + for ; Tue, 21 Feb 2012 10:15:19 +0100 (CET) +Received: by mail.jade-hamburg.de (Postfix, from userid 401) + id 601CADF2A4; Tue, 21 Feb 2012 10:15:19 +0100 (CET) +Received: from thinkbox.jade-hamburg.de + (dslb-088-075-032-221.pools.arcor-ip.net [88.75.32.221]) + (using TLSv1 with cipher AES256-SHA (256/256 bits)) + (No client certificate requested) (Authenticated sender: teythoon) + by mail.jade-hamburg.de (Postfix) with ESMTPSA id 25E61DF2A1; + Tue, 21 Feb 2012 10:15:13 +0100 (CET) +Received: from teythoon by thinkbox.jade-hamburg.de with local (Exim 4.77) + (envelope-from ) + id 1RzloT-0005aC-O7; Tue, 21 Feb 2012 10:15:09 +0100 +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: quoted-printable +From: Justus Winter <4winter@informatik.uni-hamburg.de> +User-Agent: alot/0.21+ +To: Daniel Schoepe , + Philippe LeCavalier , notmuch@notmuchmail.org +References: <87r4xur3rv.fsf@plc.plecavalier.com> + <87fweamenf.fsf@schoepe.localhost> +In-Reply-To: <87fweamenf.fsf@schoepe.localhost> +Date: Tue, 21 Feb 2012 09:15:09 -0000 +Message-ID: <20120221091509.8534.59492@thinkbox.jade-hamburg.de> +Subject: Re: nomuch_addresses.py +Date: Tue, 21 Feb 2012 10:15:09 +0100 +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Tue, 21 Feb 2012 09:15:25 -0000 + +Quoting Daniel Schoepe (2012-02-17 02:28:52) [emphasis mine]: +>Just for completeness: I'm using the nice nottoomuch-addresses.pl script +>[1] by Tomi Ollila *which doesn't require any bindings* and is incredibly +>fast (after generating an initial address database). + +I don't get it. The perl script isn't using any library bindings, +mainly because there are no libnotmuch bindings for perl. *But* it +does call the notmuch binary which is worse: + +* incredibly high overhead (fork&exec) compared to a simple function + call (plus maybe some kind of ffi) +* manual and error prone serialization of ''function arguments'' +* manual and error prone deserialization of ''return values'' +* very limited error reporting and handling capabilities +* any kind of resource (think handle to a xapian database) is lost if + the process exists resulting in further overhead if the binary is + called multiple times + +I do get the feeling that it is perceived as desirable not to require +any kind of notmuch bindings (David once said something similar about +nmbug). + +If that's the case I'd love to hear why and if there's anything we can +do about it. + +Justus -- 2.26.2