b0/5fd5ce4cb6503df9c81841b85be0971a458e79

   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 6888F431FD0\r
   6         for <notmuch@notmuchmail.org>; Fri, 27 May 2011 11:04:34 -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 hLG693irdLfW for <notmuch@notmuchmail.org>;\r
  17         Fri, 27 May 2011 11:04:33 -0700 (PDT)\r
  18 Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com\r
  19         [74.125.82.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 84D57431FB6\r
  22         for <notmuch@notmuchmail.org>; Fri, 27 May 2011 11:04:33 -0700 (PDT)\r
  23 Received: by wyi11 with SMTP id 11so1649289wyi.26\r
  24         for <notmuch@notmuchmail.org>; Fri, 27 May 2011 11:04:32 -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=QTTqPztYvAINquWVhJ4Fkm3VHDde+swnQ/Ivdk+2ZWU=;\r
  30         b=vuQf9FnFXaOovjPaLhhgrhnuhqHtIcV/O91bnPGZoXlF1JeAvOCSNpjnb+PZ5ksYw7\r
  31         xgRn7Gvfu9uRPfoooMf1ewICv7uA4f3AbEbTf5cKXA5yD+AtAwfRlEKFEts02C41EJxd\r
  32         ndPN6T+hfDBFpjNJbEhsgVMbkeUZUu1GOemC4=\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=YFD7gqVUyVdVr/z9fxWXhqKiX0VExjnew7/MVXEb9kl6TPGyYbaAQSRNt7KLBv+lYY\r
  37         gnro4nTO+OBnxAjJYlttdZNhtZ3HaJ3uw/WRAMOZa/X9Q8kalgQjqIEBr7/pSmuVSU63\r
  38         83ys/LCr57pZ/zwYw8sDjE6Pr0pJXpmwST1Ts=\r
  39 Received: by 10.216.136.207 with SMTP id w57mr7141300wei.63.1306519471843;\r
  40         Fri, 27 May 2011 11:04:31 -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 fw15sm1355413wbb.44.2011.05.27.11.04.28\r
  44         (version=TLSv1/SSLv3 cipher=OTHER);\r
  45         Fri, 27 May 2011 11:04:30 -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=Uk+bNB8sCZLVb86q-Kjfx1udEZA@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         <1306442683-sup-9315@brick> <20110526214302.GR29861@mit.edu>\r
  53         <1306446621-sup-3184@brick>\r
  54         <BANLkTi=Uk+bNB8sCZLVb86q-Kjfx1udEZA@mail.gmail.com>\r
  55 Date: Fri, 27 May 2011 19:04:27 +0100\r
  56 Message-Id: <1306518628-sup-5396@brick>\r
  57 User-Agent: Sup/git\r
  58 Content-Transfer-Encoding: 8bit\r
  59 MIME-Version: 1.0\r
  60 Content-Type: multipart/signed; boundary="=-1306519467-975049-22881-1746-2-=";\r
  61         protocol="application/pgp-signature"\r
  62 Cc: Patrick Totzke <patricktotzke@googlemail.com>,\r
  63         notmuch <notmuch@notmuchmail.org>\r
  64 X-BeenThere: notmuch@notmuchmail.org\r
  65 X-Mailman-Version: 2.1.13\r
  66 Precedence: list\r
  67 List-Id: "Use and development of the notmuch mail system."\r
  68         <notmuch.notmuchmail.org>\r
  69 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  70         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  71 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  72 List-Post: <mailto:notmuch@notmuchmail.org>\r
  73 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  74 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  75         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  76 X-List-Received-Date: Fri, 27 May 2011 18:04:34 -0000\r
  77 \r
  78 \r
  79 --=-1306519467-975049-22881-1746-2-=\r
  80 Content-Type: text/plain; charset=UTF-8\r
  81 Content-Transfer-Encoding: quoted-printable\r
  82 \r
  83 Excerpts from Austin Clements's message of Fri May 27 03:41:44 +0100 2011=\r
  84 :\r
  85 > >> > > Have you tried simply calling list() on your thread\r
  86 > >> > > iterator to see how expensive it is? =C2=A0My bet is that it's q=\r
  87 uite cheap,\r
  88 > >> > > both memory-wise and CPU-wise.\r
  89 > >> > Funny thing:\r
  90 > >> > =C2=A0q=3DDatabase().create_query('*')\r
  91 > >> > =C2=A0time tlist =3D list(q.search_threads())\r
  92 > >> > raises a NotmuchError(STATUS.NOT_INITIALIZED) exception. For some =\r
  93 reason\r
  94 > >> > the list constructor must read mere than once from the iterator.\r
  95 > >> > So this is not an option, but even if it worked, it would show\r
  96 > >> > the same behaviour as my above test..\r
  97 > >>\r
  98 > >> Interesting. =C2=A0Looks like the Threads class implements __len__ a=\r
  99 nd that\r
 100 > >> its implementation exhausts the iterator. =C2=A0Which isn't a great =\r
 101 idea in\r
 102 > >> itself, but it turns out that Python's implementation of list() call=\r
 103 s\r
 104 > >> __len__ if it's available (presumably to pre-size the list) before\r
 105 > >> iterating over the object, so it exhausts the iterator before even\r
 106 > >> using it.\r
 107 > >>\r
 108 > >> That said, if list(q.search_threads()) did work, it wouldn't give yo=\r
 109 u\r
 110 > >> better performance than your experiment above.\r
 111 true. Nevertheless I think that list(q.search_threads())\r
 112 should be equivalent to [t for t in q.search_threads()], which is\r
 113 something to be fixed in the bindings. Should I file an issue somehow?\r
 114 Or is enough to state this as a TODO here on the list?\r
 115 \r
 116 > >> > would it be very hard to implement a Query.search_thread_ids() ?\r
 117 > >> > This name is a bit off because it had to be done on a lower level.=\r
 118 \r
 119 > >>\r
 120 > >> Lazily fetching the thread metadata on the C side would probably\r
 121 > >> address your problem automatically. =C2=A0But what are you doing tha=\r
 122 t\r
 123 > >> doesn't require any information about the threads you're manipulatin=\r
 124 g?\r
 125 > > Agreed. Unfortunately, there seems to be no way to get a list of thre=\r
 126 ad\r
 127 > > ids or a reliable iterator thereof by using the current python bindin=\r
 128 gs.\r
 129 > > It would be enough for me to have the ids because then I could\r
 130 > > search for the few threads I actually need individually on demand.\r
 131 > =\r
 132 \r
 133 > There's no way to do that from the C API either, so don't feel left\r
 134 > out.  ]:--8)  It seems to me that the right solution to your problem\r
 135 > is to make thread information lazy (effectively, everything gathered\r
 136 > in lib/thread.cc:_thread_add_message).  Then you could probably\r
 137 > materialize that iterator cheaply. =\r
 138 \r
 139 Alright. I'll put this on my mental notmuch wish list and =\r
 140 \r
 141 hope that someone will have addressed this before I run out of\r
 142 ideas how to improve my UI and have time to look at this myself.\r
 143 For now, I go with the [t.get_thread_id for t in q.search_threads()]\r
 144 approach to cache the thread ids myself and live with the fact that\r
 145 this takes time for large result sets.\r
 146 \r
 147 > In fact, it's probably worth\r
 148 > trying a hack where you put dummy information in the thread object\r
 149 > from _thread_add_message and see how long it takes just to walk the\r
 150 > iterator (unfortunately I don't think profiling will help much here\r
 151 > because much of your time is probably spent waiting for I/O).\r
 152 I don't think I understand what you mean by dummy info in a thread\r
 153 object.\r
 154 \r
 155 > I don't think there would be any downside to doing this for eager\r
 156 > consumers like the CLI.\r
 157 one should think so, yes.\r
 158 /p\r
 159 \r
 160 --=-1306519467-975049-22881-1746-2-=\r
 161 Content-Disposition: attachment; filename="signature.asc"\r
 162 Content-Type: application/pgp-signature; name="signature.asc"\r
 163 \r
 164 -----BEGIN PGP SIGNATURE-----\r
 165 Version: GnuPG v1.4.11 (GNU/Linux)\r
 166 \r
 167 iEYEARECAAYFAk3f56sACgkQlDQDZ9fWxaqA9QCgpvXeNv8MJkKU+4knpY7VJC24\r
 168 VUwAoK5dFwwmSkEhtD8dLt2EYc9PqQTb\r
 169 =t6vZ\r
 170 -----END PGP SIGNATURE-----\r
 171 \r
 172 --=-1306519467-975049-22881-1746-2-=--\r