5a/786ccd5c911804399b85a7dd4b79ca61842b5b

   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 49D5B431FD0\r
   6         for <notmuch@notmuchmail.org>; Sat, 28 May 2011 01:58:11 -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 s+9hG-axKvQx for <notmuch@notmuchmail.org>;\r
  17         Sat, 28 May 2011 01:58:10 -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 EDDC2431FB6\r
  22         for <notmuch@notmuchmail.org>; Sat, 28 May 2011 01:58:09 -0700 (PDT)\r
  23 Received: by wyi11 with SMTP id 11so1991472wyi.26\r
  24         for <notmuch@notmuchmail.org>; Sat, 28 May 2011 01:58:08 -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=kXhSTCAZBxY1vsG8vZEAZpQoiaDbNh62gx2g2Bqg3JE=;\r
  30         b=o6YYAvTa4tC221hRR0/cDj2gr2XYfTr1xELHFIW5t+UvSQ8WX6ndyjIoRpoC3aut9E\r
  31         BUJDUdJaMf8AmaJD1gUy/wCnCUmH8AarcPWnZe6pTJtGTz8bT8zx/M8097uGAC+8GGIq\r
  32         5YcpQ7NyKGTjG9QA6PCt/j8w7gBaEcHz/objw=\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=dKDy5eFaHAGtiO15HVzq8L/30dNG3eSKNAbzksbqN0VIrk2u9gWsTi1jPDGSbhUO9U\r
  37         VTCOI1ugR6r3x8CHMrcU88xvujahXunVWmLeACMlbdGPcwUIgXICEd/+tDoslyRzZf52\r
  38         ks1J3JGqmCyS8QWp/gQ9/fmqkdn3Oi1eDdlOc=\r
  39 Received: by 10.227.54.196 with SMTP id r4mr2863866wbg.68.1306573088356;\r
  40         Sat, 28 May 2011 01:58:08 -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 ge4sm1712630wbb.47.2011.05.28.01.58.05\r
  44         (version=TLSv1/SSLv3 cipher=OTHER);\r
  45         Sat, 28 May 2011 01:58:06 -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=cZ50h50xf_OigTyjdfY_y34AX_g@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         <1306518628-sup-5396@brick>\r
  56         <BANLkTi=cZ50h50xf_OigTyjdfY_y34AX_g@mail.gmail.com>\r
  57 Date: Sat, 28 May 2011 09:58:03 +0100\r
  58 Message-Id: <1306572273-sup-9995@brick>\r
  59 User-Agent: Sup/git\r
  60 Content-Transfer-Encoding: 8bit\r
  61 MIME-Version: 1.0\r
  62 Content-Type: multipart/signed; boundary="=-1306573083-764234-30475-5249-1-=";\r
  63         protocol="application/pgp-signature"\r
  64 Cc: notmuch <notmuch@notmuchmail.org>\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: Sat, 28 May 2011 08:58:11 -0000\r
  78 \r
  79 \r
  80 --=-1306573083-764234-30475-5249-1-=\r
  81 Content-Type: text/plain; charset=UTF-8\r
  82 Content-Transfer-Encoding: quoted-printable\r
  83 \r
  84 Excerpts from Austin Clements's message of Fri May 27 20:29:24 +0100 2011=\r
  85 :\r
  86 > On Fri, May 27, 2011 at 2:04 PM, Patrick Totzke\r
  87 > <patricktotzke@googlemail.com> wrote:\r
  88 > > Excerpts from Austin Clements's message of Fri May 27 03:41:44 +0100 =\r
  89 2011:\r
  90 > >> >> > > Have you tried simply calling list() on your thread\r
  91 > >> >> > > iterator to see how expensive it is? =C2=A0My bet is that it'=\r
  92 s quite cheap,\r
  93 > >> >> > > both memory-wise and CPU-wise.\r
  94 > >> >> > Funny thing:\r
  95 > >> >> > =C2=A0q=3DDatabase().create_query('*')\r
  96 > >> >> > =C2=A0time tlist =3D list(q.search_threads())\r
  97 > >> >> > raises a NotmuchError(STATUS.NOT_INITIALIZED) exception. For so=\r
  98 me reason\r
  99 > >> >> > the list constructor must read mere than once from the iterator=\r
 100 .\r
 101 > >> >> > So this is not an option, but even if it worked, it would show\r
 102 > >> >> > the same behaviour as my above test..\r
 103 > >> >>\r
 104 > >> >> Interesting. =C2=A0Looks like the Threads class implements __len_=\r
 105 _ and that\r
 106 > >> >> its implementation exhausts the iterator. =C2=A0Which isn't a gre=\r
 107 at idea in\r
 108 > >> >> itself, but it turns out that Python's implementation of list() c=\r
 109 alls\r
 110 > >> >> __len__ if it's available (presumably to pre-size the list) befor=\r
 111 e\r
 112 > >> >> iterating over the object, so it exhausts the iterator before eve=\r
 113 n\r
 114 > >> >> using it.\r
 115 > >> >>\r
 116 > >> >> That said, if list(q.search_threads()) did work, it wouldn't give=\r
 117  you\r
 118 > >> >> better performance than your experiment above.\r
 119 > > true. Nevertheless I think that list(q.search_threads())\r
 120 > > should be equivalent to [t for t in q.search_threads()], which is\r
 121 > > something to be fixed in the bindings. Should I file an issue somehow=\r
 122 ?\r
 123 > > Or is enough to state this as a TODO here on the list?\r
 124 > =\r
 125 \r
 126 > Yes, they should be equivalent.\r
 127 > =\r
 128 \r
 129 > Sebastian was thinking about fixing the larger issue of generator\r
 130 > exhaustion, which would address this, though the performance would\r
 131 > depend on the cost of iterating twice.  This is why generators\r
 132 > shouldn't support __len__.  Unfortunately, it's probably hard to get\r
 133 > rid of at this point and I doubt there's a way to tell list() to\r
 134 > overlook the presence of a __len__ method.\r
 135 Why not simply removing support for __len__ in the Threads and Messages c=\r
 136 lasses?\r
 137 \r
 138 > >> >> > would it be very hard to implement a Query.search_thread_ids() =\r
 139 ?\r
 140 > >> >> > This name is a bit off because it had to be done on a lower lev=\r
 141 el.\r
 142 > >> >>\r
 143 > >> >> Lazily fetching the thread metadata on the C side would probably\r
 144 > >> >> address your problem automatically. =C2=A0But what are you doing =\r
 145 that\r
 146 > >> >> doesn't require any information about the threads you're manipula=\r
 147 ting?\r
 148 > >> > Agreed. Unfortunately, there seems to be no way to get a list of t=\r
 149 hread\r
 150 > >> > ids or a reliable iterator thereof by using the current python bin=\r
 151 dings.\r
 152 > >> > It would be enough for me to have the ids because then I could\r
 153 > >> > search for the few threads I actually need individually on demand.=\r
 154 \r
 155 > >>\r
 156 > >> There's no way to do that from the C API either, so don't feel left\r
 157 > >> out. =C2=A0]:--8) =C2=A0It seems to me that the right solution to yo=\r
 158 ur problem\r
 159 > >> is to make thread information lazy (effectively, everything gathered=\r
 160 \r
 161 > >> in lib/thread.cc:_thread_add_message). =C2=A0Then you could probably=\r
 162 \r
 163 > >> materialize that iterator cheaply.\r
 164 > > Alright. I'll put this on my mental notmuch wish list and\r
 165 > > hope that someone will have addressed this before I run out of\r
 166 > > ideas how to improve my UI and have time to look at this myself.\r
 167 > > For now, I go with the [t.get_thread_id for t in q.search_threads()]\r
 168 > > approach to cache the thread ids myself and live with the fact that\r
 169 > > this takes time for large result sets.\r
 170 > >\r
 171 > >> In fact, it's probably worth\r
 172 > >> trying a hack where you put dummy information in the thread object\r
 173 > >> from _thread_add_message and see how long it takes just to walk the\r
 174 > >> iterator (unfortunately I don't think profiling will help much here\r
 175 > >> because much of your time is probably spent waiting for I/O).\r
 176 > > I don't think I understand what you mean by dummy info in a thread\r
 177 > > object.\r
 178 > =\r
 179 \r
 180 > In _thread_add_message, rather than looking up the message's author,\r
 181 > subject, etc, just hard-code some dummy values.  Performance-wise,\r
 182 > this would simulate making the thread metadata lookup lazy, so you\r
 183 > could see if making this lazy would address your problem.\r
 184 Thanks for the clarification. I did that, and also commented out the\r
 185 lower parts of _notmuch_thread_create and this did indeed improve\r
 186 the performance, but not so much as I had hoped:\r
 187 \r
 188 In [10]: q=3DDatabase().create_query('*')\r
 189 In [11]: time T=3D[t for t in q.search_threads()]\r
 190 CPU times: user 2.43 s, sys: 0.22 s, total: 2.65 s\r
 191 Wall time: 2.66 s\r
 192 \r
 193 And I have only about 8000 mails in my index.\r
 194 Making thread lookups lazy would help, but here one would still\r
 195 create a lot of unused (empty) thread objects.\r
 196 The easiest solution to my problem would in my opinion be\r
 197 a function that queries only for thread ids without instanciating them.\r
 198 But I can't think of any other use case than mine for this\r
 199 so I guess many of you would be against adding this to the API?\r
 200 /p\r
 201 \r
 202 --=-1306573083-764234-30475-5249-1-=\r
 203 Content-Disposition: attachment; filename="signature.asc"\r
 204 Content-Type: application/pgp-signature; name="signature.asc"\r
 205 \r
 206 -----BEGIN PGP SIGNATURE-----\r
 207 Version: GnuPG v1.4.11 (GNU/Linux)\r
 208 \r
 209 iEYEARECAAYFAk3guRsACgkQlDQDZ9fWxapp0wCgwm7Ua/eLv/tP+6sPaZiNRQs5\r
 210 hYsAoM9M0WSNUF9Ja4OP1RLamMtNtZH8\r
 211 =5W3J\r
 212 -----END PGP SIGNATURE-----\r
 213 \r
 214 --=-1306573083-764234-30475-5249-1-=--\r