d7/5087ab55bfd4cdadecdaedc710369d46bf8a44

   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 6D4B5429E25\r
   6         for <notmuch@notmuchmail.org>; Thu, 26 May 2011 15:22:19 -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.514\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0.514 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, URI_HEX=1.313]\r
  14         autolearn=disabled\r
  15 Received: from olra.theworths.org ([127.0.0.1])\r
  16         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  17         with ESMTP id Cpl6dBGNfXgP for <notmuch@notmuchmail.org>;\r
  18         Thu, 26 May 2011 15:22:18 -0700 (PDT)\r
  19 Received: from mail-ww0-f45.google.com (mail-ww0-f45.google.com\r
  20  [74.125.82.45])        (using TLSv1 with cipher RC4-SHA (128/128 bits))        (No client\r
  21  certificate requested) by olra.theworths.org (Postfix) with ESMTPS id\r
  22  7B1BB431FB6    for <notmuch@notmuchmail.org>; Thu, 26 May 2011 15:22:18 -0700\r
  23  (PDT)\r
  24 Received: by wwi36 with SMTP id 36so1035544wwi.2\r
  25         for <notmuch@notmuchmail.org>; Thu, 26 May 2011 15:22:17 -0700 (PDT)\r
  26 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
  27         d=googlemail.com; s=gamma;\r
  28         h=domainkey-signature:cc:subject:from:to:in-reply-to:references:date\r
  29         :message-id:user-agent:content-transfer-encoding:mime-version\r
  30         :content-type; bh=pPYGloO5O3CBU5k0tDAhcl2/TZNywJVT2JZ99IHRfR4=;\r
  31         b=kW0xlqn7jM9dxRh015NG/YXRKihaRjgWbG8nEdP39EELGf+8Fbr5+GO101SY2FYS2X\r
  32         c1z4hjd+gP6rqSogzKCDF9RKxzQT8+zPEA2y9hUkZ6WLhbAROM4wuoEUK/QDCMLyxv3r\r
  33         lRKNFZtmM+lhQhaq3mj9FSlVo8AZZqSVrtTUo=\r
  34 DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma;\r
  35         h=cc:subject:from:to:in-reply-to:references:date:message-id\r
  36         :user-agent:content-transfer-encoding:mime-version:content-type;\r
  37         b=gaY30vbWZzhcQyPrWfk4e0YeiCbdUoIUALBk0LGRGyMQfcw+TSu0NBm3Yxhh5gddLv\r
  38         SsEW0bLpC/sPUaPECheXRG082EEyuGMqyWoLgOW4ibwP8I95RLAC7WbjFZdDoVzDlI3V\r
  39         o0XcRMPlFw7SzQwl84Tudhn/Bew6xQxXzNYfk=\r
  40 Received: by 10.227.165.10 with SMTP id g10mr1396157wby.91.1306448536167;\r
  41         Thu, 26 May 2011 15:22:16 -0700 (PDT)\r
  42 Received: from localhost (cpc1-sgyl2-0-0-cust47.sgyl.cable.virginmedia.com\r
  43         [80.192.18.48])\r
  44         by mx.google.com with ESMTPS id en1sm775917wbb.1.2011.05.26.15.22.13\r
  45         (version=TLSv1/SSLv3 cipher=OTHER);\r
  46         Thu, 26 May 2011 15:22:14 -0700 (PDT)\r
  47 Subject: Re: one-time-iterators\r
  48 From: Patrick Totzke <patricktotzke@googlemail.com>\r
  49 To: Austin Clements <amdragon@mit.edu>\r
  50 In-reply-to: <20110526214302.GR29861@mit.edu>\r
  51 References: <1306397849-sup-3304@brick> <877h9d9y5m.fsf@yoom.home.cworth.org>\r
  52         <BANLkTi=3mQYJft4s9jGaoqSbcJvqhmZXyQ@mail.gmail.com>\r
  53         <1306442683-sup-9315@brick> <20110526214302.GR29861@mit.edu>\r
  54 Date: Thu, 26 May 2011 23:22:11 +0100\r
  55 Message-Id: <1306446621-sup-3184@brick>\r
  56 User-Agent: Sup/git\r
  57 Content-Transfer-Encoding: 8bit\r
  58 MIME-Version: 1.0\r
  59 Content-Type: multipart/signed; boundary="=-1306448531-827817-32122-6706-2-=";\r
  60         protocol="application/pgp-signature"\r
  61 Cc: notmuch@notmuchmail.org\r
  62 X-BeenThere: notmuch@notmuchmail.org\r
  63 X-Mailman-Version: 2.1.13\r
  64 Precedence: list\r
  65 List-Id: "Use and development of the notmuch mail system."\r
  66         <notmuch.notmuchmail.org>\r
  67 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  68         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  69 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  70 List-Post: <mailto:notmuch@notmuchmail.org>\r
  71 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  72 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  73         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  74 X-List-Received-Date: Thu, 26 May 2011 22:22:19 -0000\r
  75 \r
  76 \r
  77 --=-1306448531-827817-32122-6706-2-=\r
  78 Content-Type: text/plain; charset=UTF-8\r
  79 Content-Transfer-Encoding: quoted-printable\r
  80 \r
  81 Excerpts from Austin Clements's message of Thu May 26 22:43:02 +0100 2011=\r
  82 :\r
  83 > http://notmuch.198994.n3.nabble.com/notmuch-s-idea-of-concurrency-faili=\r
  84 ng-an-invocation-tp2373468p2565731.html\r
  85 ah, good old peterson :P thanks.\r
  86 \r
  87 > > > Though, Patrick, that solution doesn't address your problem.=C2=A0 =\r
  88 On the\r
  89 > > > other hand, it's not clear to me what concurrent access semantics\r
  90 > > > you're actually expecting.=C2=A0 I suspect you don't want the remai=\r
  91 ning\r
  92 > > > iteration to reflect the changes, since your changes could equally\r
  93 > > > well have affected earlier iteration results.=C2=A0\r
  94 > > That's right. =\r
  95 \r
  96 > > > But if you want a\r
  97 > > > consistent view of your query results, something's going to have to=\r
  98 \r
  99 > > > materialize that iterator, and it might as well be you (or Xapian\r
 100 > > > would need more sophisticated concurrency control than it has).=C2=A0=\r
 101  But\r
 102 > > > this shouldn't be expensive because all you need to materialize are=\r
 103 \r
 104 > > > the document ids; you shouldn't need to eagerly fetch the per-threa=\r
 105 d\r
 106 > > > information.  =\r
 107 \r
 108 > > I thought so, but it seems that Query.search_threads() already\r
 109 > > caches more than the id of each item. Which is as expected\r
 110 > > because it is designed to return thread objects, not their ids.\r
 111 > > As you can see above, this _is_ too expensive for me.\r
 112 > =\r
 113 \r
 114 > I'd forgotten that constructing threads on the C side was eager about\r
 115 > the thread tags, author list and subject (which, without Istvan's\r
 116 > proposed patch, even requires opening and parsing the message file).\r
 117 > This is probably what's killing you.\r
 118 > =\r
 119 \r
 120 > Out of curiosity, what is your situation that you won't wind up paying\r
 121 > the cost of this iteration one way or the other and that the latency\r
 122 > of doing these tag changes matters?\r
 123 \r
 124 I'm trying to implement a terminal interface for notmuch in python\r
 125 that resembles sup.\r
 126 For the search results view, i read an initial portion from a Threads ite=\r
 127 rator =\r
 128 \r
 129 to fill my teminal window with threadline-widgets. Obviously, for a\r
 130 large number of results I don't want to go through all of them.\r
 131 The problem arises if you toggle a tag on the selected threadline and aft=\r
 132 erwards\r
 133 continue to scroll down.\r
 134 \r
 135 > > > Have you tried simply calling list() on your thread\r
 136 > > > iterator to see how expensive it is?  My bet is that it's quite che=\r
 137 ap,\r
 138 > > > both memory-wise and CPU-wise.\r
 139 > > Funny thing:\r
 140 > >  q=3DDatabase().create_query('*')\r
 141 > >  time tlist =3D list(q.search_threads())\r
 142 > > raises a NotmuchError(STATUS.NOT_INITIALIZED) exception. For some rea=\r
 143 son\r
 144 > > the list constructor must read mere than once from the iterator.\r
 145 > > So this is not an option, but even if it worked, it would show\r
 146 > > the same behaviour as my above test..\r
 147 > =\r
 148 \r
 149 > Interesting.  Looks like the Threads class implements __len__ and that\r
 150 > its implementation exhausts the iterator.  Which isn't a great idea in\r
 151 > itself, but it turns out that Python's implementation of list() calls\r
 152 > __len__ if it's available (presumably to pre-size the list) before\r
 153 > iterating over the object, so it exhausts the iterator before even\r
 154 > using it.\r
 155 > =\r
 156 \r
 157 > That said, if list(q.search_threads()) did work, it wouldn't give you\r
 158 > better performance than your experiment above.\r
 159 > =\r
 160 \r
 161 > > would it be very hard to implement a Query.search_thread_ids() ?\r
 162 > > This name is a bit off because it had to be done on a lower level.\r
 163 > =\r
 164 \r
 165 > Lazily fetching the thread metadata on the C side would probably\r
 166 > address your problem automatically.  But what are you doing that\r
 167 > doesn't require any information about the threads you're manipulating?\r
 168 Agreed. Unfortunately, there seems to be no way to get a list of thread\r
 169 ids or a reliable iterator thereof by using the current python bindings.\r
 170 It would be enough for me to have the ids because then I could\r
 171 search for the few threads I actually need individually on demand.\r
 172 \r
 173 Here is the branch in which I'm trying out these things. Sorry for the\r
 174 messy code, its late :P\r
 175 https://github.com/pazz/notmuch-gui/tree/toggletags\r
 176 \r
 177 /p\r
 178 \r
 179 --=-1306448531-827817-32122-6706-2-=\r
 180 Content-Disposition: attachment; filename="signature.asc"\r
 181 Content-Type: application/pgp-signature; name="signature.asc"\r
 182 \r
 183 -----BEGIN PGP SIGNATURE-----\r
 184 Version: GnuPG v1.4.11 (GNU/Linux)\r
 185 \r
 186 iEYEARECAAYFAk3e0pMACgkQlDQDZ9fWxaqKuQCfTm9nYgX4HJb2+tZlZUuGnXfp\r
 187 mBcAn1pyXaVzNQR9dJfIgHCyGSv/G6hl\r
 188 =X10m\r
 189 -----END PGP SIGNATURE-----\r
 190 \r
 191 --=-1306448531-827817-32122-6706-2-=--\r