db/a282a820d597de43c53a50fa446a85df058711

   1 Return-Path: <patricktotzke@googlemail.com>\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 440E4429E28\r
   6         for <notmuch@notmuchmail.org>; Thu, 26 May 2011 14:47:49 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.799\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5\r
  12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
  13         FREEMAIL_FROM=0.001, 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 w7DehrVHubty for <notmuch@notmuchmail.org>;\r
  17         Thu, 26 May 2011 14:47:48 -0700 (PDT)\r
  18 Received: from mail-ww0-f41.google.com (mail-ww0-f41.google.com\r
  19  [74.125.82.41])        (using TLSv1 with cipher RC4-SHA (128/128 bits))        (No client\r
  20  certificate requested) by olra.theworths.org (Postfix) with ESMTPS id\r
  21  E223E431FB6    for <notmuch@notmuchmail.org>; Thu, 26 May 2011 14:47:47 -0700\r
  22  (PDT)\r
  23 Received: by wwi18 with SMTP id 18so4809100wwi.2\r
  24         for <notmuch@notmuchmail.org>; Thu, 26 May 2011 14:47:46 -0700 (PDT)\r
  25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
  26         d=googlemail.com; s=gamma;\r
  27         h=domainkey-signature:cc:subject:from:to:in-reply-to:references:date\r
  28         :message-id:user-agent:content-transfer-encoding:mime-version\r
  29         :content-type; bh=Pyr3gAlEQ8tLu+6WfCLXTf6XAsWSdocNr9/tbJlIo08=;\r
  30         b=Zu05y+x6JoTFAn/bvQR2FI0jVGrv3LIqGBzX1IVX8j0jtAHGG20bMNKK5QJd4LfkH4\r
  31         VkPzWGWnUVL1p6GkkI2S4ypzZyIOO4cI08q12/8a78HRqYKt+dfW+bhdnIqzDZROqf2u\r
  32         WmhI6xr+CdFP/ZQ32awY6465+ZABtpAeg6VEc=\r
  33 DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma;\r
  34         h=cc:subject:from:to:in-reply-to:references:date:message-id\r
  35         :user-agent:content-transfer-encoding:mime-version:content-type;\r
  36         b=JSJ/ruVrztAqV4hyscY/nnwNqktD+dyvNh0pAyIDX6PYr63XE7d+gRLH3adoHNufT6\r
  37         V7/xvHbuHjBal4qVqijLJGcaKj0xfA14qit4CtdRImn7JyZ0QH6Pgsq5CB17e7K9qsUz\r
  38         hjClP9hMftyfVlAM7h2gMoqvEvUzIhRXSIwaU=\r
  39 Received: by 10.227.54.6 with SMTP id o6mr1330767wbg.61.1306446466515;\r
  40         Thu, 26 May 2011 14:47:46 -0700 (PDT)\r
  41 Received: from localhost (cpc1-sgyl2-0-0-cust47.sgyl.cable.virginmedia.com\r
  42         [80.192.18.48])\r
  43         by mx.google.com with ESMTPS id fm14sm761526wbb.58.2011.05.26.14.47.43\r
  44         (version=TLSv1/SSLv3 cipher=OTHER);\r
  45         Thu, 26 May 2011 14:47:45 -0700 (PDT)\r
  46 Subject: Re: one-time-iterators\r
  47 From: Patrick Totzke <patricktotzke@googlemail.com>\r
  48 To: Austin Clements <amdragon@mit.edu>\r
  49 In-reply-to: <BANLkTi=3mQYJft4s9jGaoqSbcJvqhmZXyQ@mail.gmail.com>\r
  50 References: <1306397849-sup-3304@brick> <877h9d9y5m.fsf@yoom.home.cworth.org>\r
  51         <BANLkTi=3mQYJft4s9jGaoqSbcJvqhmZXyQ@mail.gmail.com>\r
  52 Date: Thu, 26 May 2011 22:47:42 +0100\r
  53 Message-Id: <1306446359-sup-9475@brick>\r
  54 User-Agent: Sup/git\r
  55 Content-Transfer-Encoding: 8bit\r
  56 MIME-Version: 1.0\r
  57 Content-Type: multipart/signed; boundary="=-1306446462-339054-32122-5398-1-=";\r
  58         protocol="application/pgp-signature"\r
  59 Cc: notmuch@notmuchmail.org\r
  60 X-BeenThere: notmuch@notmuchmail.org\r
  61 X-Mailman-Version: 2.1.13\r
  62 Precedence: list\r
  63 List-Id: "Use and development of the notmuch mail system."\r
  64         <notmuch.notmuchmail.org>\r
  65 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  66         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  67 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  68 List-Post: <mailto:notmuch@notmuchmail.org>\r
  69 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  70 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  71         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  72 X-List-Received-Date: Thu, 26 May 2011 21:47:49 -0000\r
  73 \r
  74 \r
  75 --=-1306446462-339054-32122-5398-1-=\r
  76 Content-Type: text/plain; charset=UTF-8\r
  77 Content-Transfer-Encoding: quoted-printable\r
  78 \r
  79 hehe, did it again (dropping the list from cc). I need to stop\r
  80 using sup :P thanks Austin.\r
  81 \r
  82 Excerpts from Carl Worth's message of Thu May 26 18:20:21 +0100 2011:\r
  83 > On Thu, 26 May 2011 09:31:19 +0100, Patrick Totzke <patricktotzke@googl=\r
  84 email.com> wrote:\r
  85 > > Wow. This reads really complicated. All I want to say is:\r
  86 > > if I change tags in my search-results view, I get Xapian errors :)\r
  87 > =\r
  88 \r
  89 > Yes, that's frustrating. I wish that we had a more reliable interface a=\r
  90 t\r
  91 > the notmuch library level. But I'm not entirely sure what would be the\r
  92 > best way to do this.\r
  93 Actually, I expected something like this. For this reason each sup instan=\r
  94 ce =\r
  95 \r
  96 locks its index.\r
  97 At the moment I'm going for custom wrapper classes around notmuch.Thread\r
  98 and notmuch.Messages that cache the result of the calls relevant for me.\r
  99 But the real issue seems to be the iterator:\r
 100 It takes an awful lot of time just to copy the thread ids of all threads =\r
 101 from =\r
 102 \r
 103 large a query result.\r
 104 \r
 105 I tried the following in ipython:\r
 106  q=3DDatabase().create_query('*')\r
 107  time tids =3D [t.get_thread_id() for t in q.search_threads()]\r
 108 \r
 109 which results in\r
 110 CPU times: user 7.64 s, sys: 2.06 s, total: 9.70 s\r
 111 Wall time: 9.84 s\r
 112 \r
 113 It would really help if the Query object could return an iterator\r
 114 of thread-ids that makes this copying unnecessary. Is it possible to\r
 115 implement this? Or would this require the same amount of copying to happe=\r
 116 n\r
 117 at a lower level?\r
 118 I have not looked into the code for the bindings or the C code so far,\r
 119 but I guess the Query.search_threads() translates to some =\r
 120 \r
 121 "SELECT id,morestuff from threads"\r
 122 where for me a "SELECT is from threads" would totally suffice. Copying =\r
 123 \r
 124 (in the C code) only the ids so some list that yields an iterator should =\r
 125 be faster.\r
 126 \r
 127 > > The question: How do you solve this in the emacs code?\r
 128 > > do you store all tids of a query? =\r
 129 \r
 130 > =\r
 131 \r
 132 > The emacs code does not use the notmuch library interface like your\r
 133 > python bindings do. Instead, it uses the notmuch command-line tool, (an=\r
 134 d\r
 135 > buffers up the text output by it). =\r
 136 \r
 137 Ahh ok. Thanks for the explanation.\r
 138 \r
 139 Excerpts from Austin Clements's message of Thu May 26 21:18:53 +0100 2011=\r
 140 :\r
 141 > I proposed a solution to this problem a while ago\r
 142 > (id:"AANLkTi=3DKOx8aTJipkiArFVjEHE6zt_JypoASMiiAWBZ6@mail.gmail.com"),\r
 143 > though I haven't tried implementing it yet.\r
 144 Sorry, I wasn't on the list back then.\r
 145 \r
 146 > Though, Patrick, that solution doesn't address your problem.=C2=A0 On t=\r
 147 he\r
 148 > other hand, it's not clear to me what concurrent access semantics\r
 149 > you're actually expecting.=C2=A0 I suspect you don't want the remaining=\r
 150 \r
 151 > iteration to reflect the changes, since your changes could equally\r
 152 > well have affected earlier iteration results.=C2=A0\r
 153 That's right. =\r
 154 \r
 155 > But if you want a\r
 156 > consistent view of your query results, something's going to have to\r
 157 > materialize that iterator, and it might as well be you (or Xapian\r
 158 > would need more sophisticated concurrency control than it has).=C2=A0 B=\r
 159 ut\r
 160 > this shouldn't be expensive because all you need to materialize are\r
 161 > the document ids; you shouldn't need to eagerly fetch the per-thread\r
 162 > information.  =\r
 163 \r
 164 I thought so, but it seems that Query.search_threads() already\r
 165 caches more than the id of each item. Which is as expected\r
 166 because it is designed to return thread objects, not their ids.\r
 167 As you can see above, this _is_ too expensive for me.\r
 168 \r
 169 > Have you tried simply calling list() on your thread\r
 170 > iterator to see how expensive it is?  My bet is that it's quite cheap,\r
 171 > both memory-wise and CPU-wise.\r
 172 Funny thing:\r
 173  q=3DDatabase().create_query('*')\r
 174  time tlist =3D list(q.search_threads())\r
 175 raises a NotmuchError(STATUS.NOT_INITIALIZED) exception. For some reason\r
 176 the list constructor must read mere than once from the iterator.\r
 177 So this is not an option, but even if it worked, it would show\r
 178 the same behaviour as my above test..\r
 179 \r
 180 would it be very hard to implement a Query.search_thread_ids() ?\r
 181 This name is a bit off because it had to be done on a lower level.\r
 182 Cheers,\r
 183 /p\r
 184 \r
 185 --=-1306446462-339054-32122-5398-1-=\r
 186 Content-Disposition: attachment; filename="signature.asc"\r
 187 Content-Type: application/pgp-signature; name="signature.asc"\r
 188 \r
 189 -----BEGIN PGP SIGNATURE-----\r
 190 Version: GnuPG v1.4.11 (GNU/Linux)\r
 191 \r
 192 iEYEARECAAYFAk3eyn4ACgkQlDQDZ9fWxaqVKACeJYzPrEY/E60dnP0b9hBGJhvo\r
 193 +VMAoK7XflpIiPibDDHdnRySul/LuQfP\r
 194 =Ez9a\r
 195 -----END PGP SIGNATURE-----\r
 196 \r
 197 --=-1306446462-339054-32122-5398-1-=--\r