7c/3d7ef1765d618ff3135bfcd58824705012bb7f

   1 Return-Path: <amdragon@gmail.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 5FE92431FD0\r
   6         for <notmuch@notmuchmail.org>; Fri, 27 May 2011 12:29:26 -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.699\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5\r
  12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001,\r
  13         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 d7yxnsMy-thq for <notmuch@notmuchmail.org>;\r
  17         Fri, 27 May 2011 12:29:25 -0700 (PDT)\r
  18 Received: from mail-qw0-f53.google.com (mail-qw0-f53.google.com\r
  19         [209.85.216.53]) (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 3CBAD431FB6\r
  22         for <notmuch@notmuchmail.org>; Fri, 27 May 2011 12:29:25 -0700 (PDT)\r
  23 Received: by qwb7 with SMTP id 7so1292064qwb.26\r
  24         for <notmuch@notmuchmail.org>; Fri, 27 May 2011 12:29:24 -0700 (PDT)\r
  25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
  26         h=domainkey-signature:mime-version:sender:in-reply-to:references:date\r
  27         :x-google-sender-auth:message-id:subject:from:to:cc:content-type\r
  28         :content-transfer-encoding;\r
  29         bh=kf3jqWmEfa0k0RzAXXx5a5GowCH/+zcPqUt7ehdLpNk=;\r
  30         b=Wp3TBng+cHzs2GbMQynsAlu191+JBcBRAXuvtIYKhJrFES9vJhXuxUc7zXk7Ozr0Va\r
  31         DzRO4gwXcwHPO6PDM2UjCtsd9qNCBty3MXXlHiGBZ1Wy8/SgMJMYv8+6DsHosjaBq8qS\r
  32         7WfnEQI32TvfrPJ9DJdHnJ6dvh1RY3CpC/gYw=\r
  33 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
  34         h=mime-version:sender:in-reply-to:references:date\r
  35         :x-google-sender-auth:message-id:subject:from:to:cc:content-type\r
  36         :content-transfer-encoding;\r
  37         b=n/g+bv97+Xl/M31KEmPdBIsYyBj+TZx4SQkAd+YN3RFXUOZ+WHQ6zLJFg+24eWbWIP\r
  38         vQgHfouEWmvCx7FwY3ug2qcAxrVWYdQT5T9G3vXZf7tbXzWVgil6BB4X/f/hvsXsl2ei\r
  39         A1l+SUn9KsVSV8ZCm/bYzyOpB85euafJQqccM=\r
  40 MIME-Version: 1.0\r
  41 Received: by 10.229.43.99 with SMTP id v35mr1879992qce.8.1306524564220; Fri,\r
  42         27 May 2011 12:29:24 -0700 (PDT)\r
  43 Sender: amdragon@gmail.com\r
  44 Received: by 10.229.188.68 with HTTP; Fri, 27 May 2011 12:29:24 -0700 (PDT)\r
  45 In-Reply-To: <1306518628-sup-5396@brick>\r
  46 References: <1306397849-sup-3304@brick> <877h9d9y5m.fsf@yoom.home.cworth.org>\r
  47         <BANLkTi=3mQYJft4s9jGaoqSbcJvqhmZXyQ@mail.gmail.com>\r
  48         <1306442683-sup-9315@brick> <20110526214302.GR29861@mit.edu>\r
  49         <1306446621-sup-3184@brick>\r
  50         <BANLkTi=Uk+bNB8sCZLVb86q-Kjfx1udEZA@mail.gmail.com>\r
  51         <1306518628-sup-5396@brick>\r
  52 Date: Fri, 27 May 2011 15:29:24 -0400\r
  53 X-Google-Sender-Auth: UshyP3vImhrQ5skBKML1XvyreUY\r
  54 Message-ID: <BANLkTi=cZ50h50xf_OigTyjdfY_y34AX_g@mail.gmail.com>\r
  55 Subject: Re: one-time-iterators\r
  56 From: Austin Clements <amdragon@mit.edu>\r
  57 To: Patrick Totzke <patricktotzke@googlemail.com>,\r
  58         Sebastian Spaeth <sebastian@sspaeth.de>\r
  59 Content-Type: text/plain; charset=ISO-8859-1\r
  60 Content-Transfer-Encoding: quoted-printable\r
  61 Cc: notmuch <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: Fri, 27 May 2011 19:29:26 -0000\r
  75 \r
  76 On Fri, May 27, 2011 at 2:04 PM, Patrick Totzke\r
  77 <patricktotzke@googlemail.com> wrote:\r
  78 > Excerpts from Austin Clements's message of Fri May 27 03:41:44 +0100 2011=\r
  79 :\r
  80 >> >> > > Have you tried simply calling list() on your thread\r
  81 >> >> > > iterator to see how expensive it is? =A0My bet is that it's quite=\r
  82  cheap,\r
  83 >> >> > > both memory-wise and CPU-wise.\r
  84 >> >> > Funny thing:\r
  85 >> >> > =A0q=3DDatabase().create_query('*')\r
  86 >> >> > =A0time tlist =3D list(q.search_threads())\r
  87 >> >> > raises a NotmuchError(STATUS.NOT_INITIALIZED) exception. For some r=\r
  88 eason\r
  89 >> >> > the list constructor must read mere than once from the iterator.\r
  90 >> >> > So this is not an option, but even if it worked, it would show\r
  91 >> >> > the same behaviour as my above test..\r
  92 >> >>\r
  93 >> >> Interesting. =A0Looks like the Threads class implements __len__ and t=\r
  94 hat\r
  95 >> >> its implementation exhausts the iterator. =A0Which isn't a great idea=\r
  96  in\r
  97 >> >> itself, but it turns out that Python's implementation of list() calls\r
  98 >> >> __len__ if it's available (presumably to pre-size the list) before\r
  99 >> >> iterating over the object, so it exhausts the iterator before even\r
 100 >> >> using it.\r
 101 >> >>\r
 102 >> >> That said, if list(q.search_threads()) did work, it wouldn't give you\r
 103 >> >> better performance than your experiment above.\r
 104 > true. Nevertheless I think that list(q.search_threads())\r
 105 > should be equivalent to [t for t in q.search_threads()], which is\r
 106 > something to be fixed in the bindings. Should I file an issue somehow?\r
 107 > Or is enough to state this as a TODO here on the list?\r
 108 \r
 109 Yes, they should be equivalent.\r
 110 \r
 111 Sebastian was thinking about fixing the larger issue of generator\r
 112 exhaustion, which would address this, though the performance would\r
 113 depend on the cost of iterating twice.  This is why generators\r
 114 shouldn't support __len__.  Unfortunately, it's probably hard to get\r
 115 rid of at this point and I doubt there's a way to tell list() to\r
 116 overlook the presence of a __len__ method.\r
 117 \r
 118 >> >> > would it be very hard to implement a Query.search_thread_ids() ?\r
 119 >> >> > This name is a bit off because it had to be done on a lower level.\r
 120 >> >>\r
 121 >> >> Lazily fetching the thread metadata on the C side would probably\r
 122 >> >> address your problem automatically. =A0But what are you doing that\r
 123 >> >> doesn't require any information about the threads you're manipulating=\r
 124 ?\r
 125 >> > Agreed. Unfortunately, there seems to be no way to get a list of threa=\r
 126 d\r
 127 >> > ids or a reliable iterator thereof by using the current python binding=\r
 128 s.\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 >> There's no way to do that from the C API either, so don't feel left\r
 133 >> out. =A0]:--8) =A0It seems to me that the right solution to your problem\r
 134 >> is to make thread information lazy (effectively, everything gathered\r
 135 >> in lib/thread.cc:_thread_add_message). =A0Then you could probably\r
 136 >> materialize that iterator cheaply.\r
 137 > Alright. I'll put this on my mental notmuch wish list and\r
 138 > hope that someone will have addressed this before I run out of\r
 139 > ideas how to improve my UI and have time to look at this myself.\r
 140 > For now, I go with the [t.get_thread_id for t in q.search_threads()]\r
 141 > approach to cache the thread ids myself and live with the fact that\r
 142 > this takes time for large result sets.\r
 143 >\r
 144 >> In fact, it's probably worth\r
 145 >> trying a hack where you put dummy information in the thread object\r
 146 >> from _thread_add_message and see how long it takes just to walk the\r
 147 >> iterator (unfortunately I don't think profiling will help much here\r
 148 >> because much of your time is probably spent waiting for I/O).\r
 149 > I don't think I understand what you mean by dummy info in a thread\r
 150 > object.\r
 151 \r
 152 In _thread_add_message, rather than looking up the message's author,\r
 153 subject, etc, just hard-code some dummy values.  Performance-wise,\r
 154 this would simulate making the thread metadata lookup lazy, so you\r
 155 could see if making this lazy would address your problem.\r