f9/d082930c84a86dbd98073a56f55c08c37c5099

   1 Return-Path: <tomi.ollila@iki.fi>\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 1D512431FAF\r
   6         for <notmuch@notmuchmail.org>; Tue, 21 Feb 2012 03:23:16 -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\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
  12         autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id oth3pO9UUnKp for <notmuch@notmuchmail.org>;\r
  16         Tue, 21 Feb 2012 03:23:12 -0800 (PST)\r
  17 Received: from guru.guru-group.fi (guru-group.fi [87.108.86.66])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 29FB8431FAE\r
  19         for <notmuch@notmuchmail.org>; Tue, 21 Feb 2012 03:23:12 -0800 (PST)\r
  20 Received: by guru.guru-group.fi (Postfix, from userid 501)\r
  21         id 4CFCA68055; Tue, 21 Feb 2012 13:23:11 +0200 (EET)\r
  22 From: Tomi Ollila <tomi.ollila@iki.fi>\r
  23 To: Justus Winter <4winter@informatik.uni-hamburg.de>,\r
  24         Daniel Schoepe <daniel@schoepe.org>,\r
  25         Philippe LeCavalier <support@plecavalier.com>, notmuch@notmuchmail.org\r
  26 Subject: Re: nomuch_addresses.py\r
  27 In-Reply-To: <20120221091509.8534.59492@thinkbox.jade-hamburg.de>\r
  28 References: <87r4xur3rv.fsf@plc.plecavalier.com>\r
  29         <87fweamenf.fsf@schoepe.localhost>\r
  30         <20120221091509.8534.59492@thinkbox.jade-hamburg.de>\r
  31 User-Agent: Notmuch/0.11.1+198~g922c4d2 (http://notmuchmail.org) Emacs/23.3.1\r
  32         (x86_64-unknown-linux-gnu)\r
  33 X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
  34         $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
  35         !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
  36 Date: Tue, 21 Feb 2012 13:23:11 +0200\r
  37 Message-ID: <m2zkcc4ehs.fsf@guru.guru-group.fi>\r
  38 MIME-Version: 1.0\r
  39 Content-Type: text/plain; charset=us-ascii\r
  40 X-BeenThere: notmuch@notmuchmail.org\r
  41 X-Mailman-Version: 2.1.13\r
  42 Precedence: list\r
  43 List-Id: "Use and development of the notmuch mail system."\r
  44         <notmuch.notmuchmail.org>\r
  45 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  46         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  47 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  48 List-Post: <mailto:notmuch@notmuchmail.org>\r
  49 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  50 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  51         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  52 X-List-Received-Date: Tue, 21 Feb 2012 11:23:16 -0000\r
  53 \r
  54 On Tue, 21 Feb 2012 09:15:09 -0000, Justus Winter <4winter@informatik.uni-hamburg.de> wrote:\r
  55 > Quoting Daniel Schoepe (2012-02-17 02:28:52) [emphasis mine]:\r
  56 > >Just for completeness: I'm using the nice nottoomuch-addresses.pl script\r
  57 > >[1] by Tomi Ollila *which doesn't require any bindings* and is incredibly\r
  58 > >fast (after generating an initial address database).\r
  59 > \r
  60 > I don't get it. The perl script isn't using any library bindings,\r
  61 > mainly because there are no libnotmuch bindings for perl. *But* it\r
  62 > does call the notmuch binary which is worse:\r
  63 > \r
  64 > * incredibly high overhead (fork&exec) compared to a simple function\r
  65 >   call (plus maybe some kind of ffi)\r
  66 > * manual and error prone serialization of ''function arguments''\r
  67 > * manual and error prone deserialization of ''return values''\r
  68 > * very limited error reporting and handling capabilities\r
  69 > * any kind of resource (think handle to a xapian database) is lost if\r
  70 >   the process exists resulting in further overhead if the binary is\r
  71 >   called multiple times\r
  72 \r
  73 Shortly answering nottoomuch-addresses.sh's (version 2.0) point of view.\r
  74 \r
  75 Searching from "database" is done using fgrep. that means 2 forks, 2 execs\r
  76 from command line (it used to be one fork but now we handle fgrep return\r
  77 value) (fork, exec /bin/sh, fork, exec fgrep). Anyway, usually matches are\r
  78 printed out by fgrep before ENTER key has risen (or TAB when run from\r
  79 emacs).\r
  80 \r
  81 The "database" is created by perl program ("embedded" in\r
  82 nottoomuch-addresses.sh), it executes notmuch once to get all email\r
  83 filenames (since beginning of time or since last update) -- the perl code\r
  84 then parses email addresses out of those files, cleans those up, removes\r
  85 duplicates and writes those to the "database" files (all and one with\r
  86 ignored removed)... So that newest are in top of the file, returned first\r
  87 in fgrep(1) execution.\r
  88 \r
  89 > I do get the feeling that it is perceived as desirable not to require\r
  90 > any kind of notmuch bindings (David once said something similar about\r
  91 > nmbug).\r
  92 > \r
  93 > If that's the case I'd love to hear why and if there's anything we can\r
  94 > do about it.\r
  95 \r
  96 It would be nice if notmuch(1) itself had command to be used for\r
  97 address completion. I wonder how feasible it is to get a good implementation\r
  98 there...\r
  99 \r
 100 > \r
 101 > Justus\r
 102 \r
 103 Tomi\r