From d458df2294452f682b7d1ad929c2b00c3f5ec0ec Mon Sep 17 00:00:00 2001 From: Daniel Schoepe Date: Tue, 21 Feb 2012 14:53:06 +0100 Subject: [PATCH] Re: nomuch_addresses.py --- 06/7d7a1fde12e4952ec79d08ce3cfca872428bfe | 155 ++++++++++++++++++++++ 1 file changed, 155 insertions(+) create mode 100644 06/7d7a1fde12e4952ec79d08ce3cfca872428bfe diff --git a/06/7d7a1fde12e4952ec79d08ce3cfca872428bfe b/06/7d7a1fde12e4952ec79d08ce3cfca872428bfe new file mode 100644 index 000000000..de0ab31df --- /dev/null +++ b/06/7d7a1fde12e4952ec79d08ce3cfca872428bfe @@ -0,0 +1,155 @@ +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 40F61431FAF + for ; Tue, 21 Feb 2012 05:53:24 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -0.8 +X-Spam-Level: +X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 + tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, + RCVD_IN_DNSWL_LOW=-0.7] 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 nUpRQO2G-BRG for ; + Tue, 21 Feb 2012 05:53:20 -0800 (PST) +Received: from mail-ey0-f181.google.com (mail-ey0-f181.google.com + [209.85.215.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id 867AB431FAE + for ; Tue, 21 Feb 2012 05:53:20 -0800 (PST) +Received: by eaak14 with SMTP id k14so3609646eaa.26 + for ; Tue, 21 Feb 2012 05:53:19 -0800 (PST) +Received-SPF: pass (google.com: domain of daniel@schoepe.org designates + 10.14.45.80 as permitted sender) client-ip=10.14.45.80; +Authentication-Results: mr.google.com; + spf=pass (google.com: domain of daniel@schoepe.org + designates 10.14.45.80 as permitted sender) + smtp.mail=daniel@schoepe.org; + dkim=pass header.i=daniel@schoepe.org +Received: from mr.google.com ([10.14.45.80]) + by 10.14.45.80 with SMTP id o56mr8482815eeb.88.1329832399241 (num_hops + = 1); Tue, 21 Feb 2012 05:53:19 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=schoepe.org; s=google; + h=from:to:subject:in-reply-to:references:user-agent:date:message-id + :mime-version:content-type; + bh=wfPtkw7qM5lO1/XjeJMZnXkxMsWcdOnpcK7/RuEwluU=; + b=bkQtZeiCRF+dFRaz+qUhsejx0an0jn6s6WB204Bzf6dBBPf8HhEvXBnn681tasTX/u + VDeSUwRveCTmUuyd6TqfAHWO9uu31zZrcvHfk+8LvvapGuFXI80WtCp1lzFrxmqoXiFF + vUMPtlRQkKAbxYDJnlPrhXX2XLpso/0xNcigQ= +Received: by 10.14.45.80 with SMTP id o56mr6725463eeb.88.1329832399085; + Tue, 21 Feb 2012 05:53:19 -0800 (PST) +Received: from localhost (p4FC78DCA.dip0.t-ipconnect.de. [79.199.141.202]) + by mx.google.com with ESMTPS id s48sm87896441eem.0.2012.02.21.05.53.17 + (version=TLSv1/SSLv3 cipher=OTHER); + Tue, 21 Feb 2012 05:53:17 -0800 (PST) +From: Daniel Schoepe +To: Justus Winter <4winter@informatik.uni-hamburg.de>, + Philippe LeCavalier , notmuch@notmuchmail.org +Subject: Re: nomuch_addresses.py +In-Reply-To: <20120221091509.8534.59492@thinkbox.jade-hamburg.de> +References: <87r4xur3rv.fsf@plc.plecavalier.com> + <87fweamenf.fsf@schoepe.localhost> + <20120221091509.8534.59492@thinkbox.jade-hamburg.de> +User-Agent: Notmuch/0.11.1+210~ge886eec (http://notmuchmail.org) + Emacs/24.0.93.1 (x86_64-pc-linux-gnu) +Date: Tue, 21 Feb 2012 14:53:06 +0100 +Message-ID: <87zkccjnst.fsf@schoepe.localhost> +MIME-Version: 1.0 +Content-Type: multipart/signed; boundary="=-=-="; + micalg=pgp-sha1; protocol="application/pgp-signature" +X-Gm-Message-State: + ALoCoQlvryTuWvwyHgiVuqWwaGiO/OzSdZZj6r/wAVy3IdPbE0f5PTTWQ4Y4MwNG0Mc00qO88gBh +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 13:53:24 -0000 + +--=-=-= +Content-Type: text/plain +Content-Transfer-Encoding: quoted-printable + +On Tue, 21 Feb 2012 09:15:09 -0000, Justus Winter <4winter@informatik.uni-h= +amburg.de> wrote: +> 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). +>=20 +> 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: + +I think that emphasis you added may be a bit misleading: + +I specifically mentioned that it doesn't need bindings, because the +initial problem in this thread had to do with missing bindings, not +because I think it's inherently a good thing. + +The reason I mentioned nottoomuch-addresses at all, is that completion +itself is _a lot_ faster (at least for me), compared to +addrlookup. According to the wiki, notmuch-addresses.py is even slower +than addrlookup, so I thought (and still think) that it was worth +mentioning. Of course, one could rewrite the database-generation part in +python using the bindings, but I personally don't think it's that +necessary. + +> * incredibly high overhead (fork&exec) compared to a simple function +> call (plus maybe some kind of ffi) + +I think nottoomuch-addresses.sh is a good example how such performance +considerations can be outweighed by choosing a good "algorithm" instead +(extracting all addresses beforehand). + +> * 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 +>=20 +> 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). + +While I don't think that using bindings is a bad thing, the fact that we +can do non-trivial things like nmbug without them, seems to be a good +indicator for the quality of the command line interface though. (And +hence notmuch lends itself well to being used in shell scripts). + +Cheers, +Daniel + + +--=-=-= +Content-Type: application/pgp-signature + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.11 (GNU/Linux) + +iQIcBAEBAgAGBQJPQ6HCAAoJEIaTAtce+Z+JD5IQAIw+UtQfNS8MRx52YTgirM01 +X7WBznp2k8r9J5n/ii2ZrE9/nkfwc2MGWJ9F7sbdijGvwUy+M2vFHgUSow6xRmud +nVkIs7XBH/YLG927BloiM3QRmgJuwoqJLJyPWniS4Xc2q0D1QUXDVeSwzLwHD9uL +SqW3q2gLbo5ZmV716n3YUnEzYl4+cyEv5bod91qYQM8fm4mFo5JcJ4EajjP3Rz5Y +2OFf5Ou8iK9fJGQXeVXtvYtd0tpMoD7WXS56zbJ8fbRdGTABiGORxQc0VGZob2Si +hJ0+/sss7BjYbUZgN3HSjlENVtCGuEZD4ioL8J0IKgYKr+vWs7lzSwp8aNK/Gm4Q +Fukco/H10wrMvhGv9YqXz+mn4lLFYWlO1HzYRicwPjueu46sNDmPU/cMefUIDonf +DKzxhGOGQgTpBIuIn9+VDuNHBU0mWehq8hcrHb1byFeRW817UB5ouK3r5paRqY/1 +/XueSd7CD9gfi6bV01r2jQ8zxnOmisHVWjZq3DsyN7g8skpJtpybILLfQUIlhqHi +yuZJLkn2m47tY5dnmDyBeN22PiuNy22PuLUEQfM/w2NaxFxWUgI5W8VxtiKRgSCz +hQyvFJhliFebDs/AybOKTfG0tCWBdve9NTAtSv4rT2H9nnNzC71xl4ae39IOB91e +vZBT/7aJ9FRxlolFi8L8 +=3Cc/ +-----END PGP SIGNATURE----- +--=-=-=-- -- 2.26.2