06/7d7a1fde12e4952ec79d08ce3cfca872428bfe

   1 Return-Path: <daniel@schoepe.org>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 40F61431FAF\r
   6         for <notmuch@notmuchmail.org>; Tue, 21 Feb 2012 05:53:24 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.8\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5\r
  12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
  13         RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id nUpRQO2G-BRG for <notmuch@notmuchmail.org>;\r
  17         Tue, 21 Feb 2012 05:53:20 -0800 (PST)\r
  18 Received: from mail-ey0-f181.google.com (mail-ey0-f181.google.com\r
  19         [209.85.215.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id 867AB431FAE\r
  22         for <notmuch@notmuchmail.org>; Tue, 21 Feb 2012 05:53:20 -0800 (PST)\r
  23 Received: by eaak14 with SMTP id k14so3609646eaa.26\r
  24         for <notmuch@notmuchmail.org>; Tue, 21 Feb 2012 05:53:19 -0800 (PST)\r
  25 Received-SPF: pass (google.com: domain of daniel@schoepe.org designates\r
  26         10.14.45.80 as permitted sender) client-ip=10.14.45.80; \r
  27 Authentication-Results: mr.google.com;\r
  28         spf=pass (google.com: domain of daniel@schoepe.org\r
  29         designates 10.14.45.80 as permitted sender)\r
  30         smtp.mail=daniel@schoepe.org;\r
  31         dkim=pass header.i=daniel@schoepe.org\r
  32 Received: from mr.google.com ([10.14.45.80])\r
  33         by 10.14.45.80 with SMTP id o56mr8482815eeb.88.1329832399241 (num_hops\r
  34         = 1); Tue, 21 Feb 2012 05:53:19 -0800 (PST)\r
  35 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=schoepe.org; s=google;\r
  36         h=from:to:subject:in-reply-to:references:user-agent:date:message-id\r
  37         :mime-version:content-type;\r
  38         bh=wfPtkw7qM5lO1/XjeJMZnXkxMsWcdOnpcK7/RuEwluU=;\r
  39         b=bkQtZeiCRF+dFRaz+qUhsejx0an0jn6s6WB204Bzf6dBBPf8HhEvXBnn681tasTX/u\r
  40         VDeSUwRveCTmUuyd6TqfAHWO9uu31zZrcvHfk+8LvvapGuFXI80WtCp1lzFrxmqoXiFF\r
  41         vUMPtlRQkKAbxYDJnlPrhXX2XLpso/0xNcigQ=\r
  42 Received: by 10.14.45.80 with SMTP id o56mr6725463eeb.88.1329832399085;\r
  43         Tue, 21 Feb 2012 05:53:19 -0800 (PST)\r
  44 Received: from localhost (p4FC78DCA.dip0.t-ipconnect.de. [79.199.141.202])\r
  45         by mx.google.com with ESMTPS id s48sm87896441eem.0.2012.02.21.05.53.17\r
  46         (version=TLSv1/SSLv3 cipher=OTHER);\r
  47         Tue, 21 Feb 2012 05:53:17 -0800 (PST)\r
  48 From: Daniel Schoepe <daniel@schoepe.org>\r
  49 To: Justus Winter <4winter@informatik.uni-hamburg.de>,\r
  50         Philippe LeCavalier <support@plecavalier.com>, notmuch@notmuchmail.org\r
  51 Subject: Re: nomuch_addresses.py\r
  52 In-Reply-To: <20120221091509.8534.59492@thinkbox.jade-hamburg.de>\r
  53 References: <87r4xur3rv.fsf@plc.plecavalier.com>\r
  54         <87fweamenf.fsf@schoepe.localhost>\r
  55         <20120221091509.8534.59492@thinkbox.jade-hamburg.de>\r
  56 User-Agent: Notmuch/0.11.1+210~ge886eec (http://notmuchmail.org)\r
  57         Emacs/24.0.93.1 (x86_64-pc-linux-gnu)\r
  58 Date: Tue, 21 Feb 2012 14:53:06 +0100\r
  59 Message-ID: <87zkccjnst.fsf@schoepe.localhost>\r
  60 MIME-Version: 1.0\r
  61 Content-Type: multipart/signed; boundary="=-=-=";\r
  62         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  63 X-Gm-Message-State:\r
  64  ALoCoQlvryTuWvwyHgiVuqWwaGiO/OzSdZZj6r/wAVy3IdPbE0f5PTTWQ4Y4MwNG0Mc00qO88gBh\r
  65 X-BeenThere: notmuch@notmuchmail.org\r
  66 X-Mailman-Version: 2.1.13\r
  67 Precedence: list\r
  68 List-Id: "Use and development of the notmuch mail system."\r
  69         <notmuch.notmuchmail.org>\r
  70 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  71         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  72 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  73 List-Post: <mailto:notmuch@notmuchmail.org>\r
  74 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  75 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  76         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  77 X-List-Received-Date: Tue, 21 Feb 2012 13:53:24 -0000\r
  78 \r
  79 --=-=-=\r
  80 Content-Type: text/plain\r
  81 Content-Transfer-Encoding: quoted-printable\r
  82 \r
  83 On Tue, 21 Feb 2012 09:15:09 -0000, Justus Winter <4winter@informatik.uni-h=\r
  84 amburg.de> wrote:\r
  85 > Quoting Daniel Schoepe (2012-02-17 02:28:52) [emphasis mine]:\r
  86 > >Just for completeness: I'm using the nice nottoomuch-addresses.pl script\r
  87 > >[1] by Tomi Ollila *which doesn't require any bindings* and is incredibly\r
  88 > >fast (after generating an initial address database).\r
  89 >=20\r
  90 > I don't get it. The perl script isn't using any library bindings,\r
  91 > mainly because there are no libnotmuch bindings for perl. *But* it\r
  92 > does call the notmuch binary which is worse:\r
  93 \r
  94 I think that emphasis you added may be a bit misleading:\r
  95 \r
  96 I specifically mentioned that it doesn't need bindings, because the\r
  97 initial problem in this thread had to do with missing bindings, not\r
  98 because I think it's inherently a good thing.\r
  99 \r
 100 The reason I mentioned nottoomuch-addresses at all, is that completion\r
 101 itself is _a lot_ faster (at least for me), compared to\r
 102 addrlookup. According to the wiki, notmuch-addresses.py is even slower\r
 103 than addrlookup, so I thought (and still think) that it was worth\r
 104 mentioning. Of course, one could rewrite the database-generation part in\r
 105 python using the bindings, but I personally don't think it's that\r
 106 necessary.\r
 107 \r
 108 > * incredibly high overhead (fork&exec) compared to a simple function\r
 109 >   call (plus maybe some kind of ffi)\r
 110 \r
 111 I think nottoomuch-addresses.sh is a good example how such performance\r
 112 considerations can be outweighed by choosing a good "algorithm" instead\r
 113 (extracting all addresses beforehand).\r
 114 \r
 115 > * manual and error prone serialization of ''function arguments''\r
 116 > * manual and error prone deserialization of ''return values''\r
 117 > * very limited error reporting and handling capabilities\r
 118 > * any kind of resource (think handle to a xapian database) is lost if\r
 119 >   the process exists resulting in further overhead if the binary is\r
 120 >   called multiple times\r
 121 >=20\r
 122 > I do get the feeling that it is perceived as desirable not to require\r
 123 > any kind of notmuch bindings (David once said something similar about\r
 124 > nmbug).\r
 125 \r
 126 While I don't think that using bindings is a bad thing, the fact that we\r
 127 can do non-trivial things like nmbug without them, seems to be a good\r
 128 indicator for the quality of the command line interface though. (And\r
 129 hence notmuch lends itself well to being used in shell scripts).\r
 130 \r
 131 Cheers,\r
 132 Daniel\r
 133 \r
 134 \r
 135 --=-=-=\r
 136 Content-Type: application/pgp-signature\r
 137 \r
 138 -----BEGIN PGP SIGNATURE-----\r
 139 Version: GnuPG v1.4.11 (GNU/Linux)\r
 140 \r
 141 iQIcBAEBAgAGBQJPQ6HCAAoJEIaTAtce+Z+JD5IQAIw+UtQfNS8MRx52YTgirM01\r
 142 X7WBznp2k8r9J5n/ii2ZrE9/nkfwc2MGWJ9F7sbdijGvwUy+M2vFHgUSow6xRmud\r
 143 nVkIs7XBH/YLG927BloiM3QRmgJuwoqJLJyPWniS4Xc2q0D1QUXDVeSwzLwHD9uL\r
 144 SqW3q2gLbo5ZmV716n3YUnEzYl4+cyEv5bod91qYQM8fm4mFo5JcJ4EajjP3Rz5Y\r
 145 2OFf5Ou8iK9fJGQXeVXtvYtd0tpMoD7WXS56zbJ8fbRdGTABiGORxQc0VGZob2Si\r
 146 hJ0+/sss7BjYbUZgN3HSjlENVtCGuEZD4ioL8J0IKgYKr+vWs7lzSwp8aNK/Gm4Q\r
 147 Fukco/H10wrMvhGv9YqXz+mn4lLFYWlO1HzYRicwPjueu46sNDmPU/cMefUIDonf\r
 148 DKzxhGOGQgTpBIuIn9+VDuNHBU0mWehq8hcrHb1byFeRW817UB5ouK3r5paRqY/1\r
 149 /XueSd7CD9gfi6bV01r2jQ8zxnOmisHVWjZq3DsyN7g8skpJtpybILLfQUIlhqHi\r
 150 yuZJLkn2m47tY5dnmDyBeN22PiuNy22PuLUEQfM/w2NaxFxWUgI5W8VxtiKRgSCz\r
 151 hQyvFJhliFebDs/AybOKTfG0tCWBdve9NTAtSv4rT2H9nnNzC71xl4ae39IOB91e\r
 152 vZBT/7aJ9FRxlolFi8L8\r
 153 =3Cc/\r
 154 -----END PGP SIGNATURE-----\r
 155 --=-=-=--\r