Re: [PATCH v4 01/16] add util/search-path.{c, h} to test for executables in $PATH
[notmuch-archives.git] / 0f / b67781af1a6c4d62c09c7d8406b3407232b415
1 Return-Path: <m.walters@qmul.ac.uk>\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 7C8CB431FBD\r
6         for <notmuch@notmuchmail.org>; Tue, 14 Feb 2012 04:27:30 -0800 (PST)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -1.098\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5\r
12         tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
13         NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] 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 jrcJoBYri7ey for <notmuch@notmuchmail.org>;\r
17         Tue, 14 Feb 2012 04:27:30 -0800 (PST)\r
18 Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\r
19         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
20         (No client certificate requested)\r
21         by olra.theworths.org (Postfix) with ESMTPS id DA198431FBC\r
22         for <notmuch@notmuchmail.org>; Tue, 14 Feb 2012 04:27:29 -0800 (PST)\r
23 Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
24         by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
25         (envelope-from <m.walters@qmul.ac.uk>)\r
26         id 1RxHTh-0003o6-UN; Tue, 14 Feb 2012 12:27:26 +0000\r
27 Received: from 94-192-233-223.zone6.bethere.co.uk ([94.192.233.223]\r
28         helo=localhost)\r
29         by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69)\r
30         (envelope-from <m.walters@qmul.ac.uk>)\r
31         id 1RxHTh-0004nL-N4; Tue, 14 Feb 2012 12:27:25 +0000\r
32 From: Mark Walters <markwalters1009@gmail.com>\r
33 To: notmuch@notmuchmail.org\r
34 Subject: Re: [RFC PATCH v3 00/11] notmuch-pick: an emacs threaded message view\r
35         with split-pane\r
36 In-Reply-To: <1329096015-8078-1-git-send-email-markwalters1009@gmail.com>\r
37 References: <1329072579-27340-1-git-send-email-markwalters1009@gmail.com>\r
38         <1329096015-8078-1-git-send-email-markwalters1009@gmail.com>\r
39 User-Agent: Notmuch/0.11.1+203~g8b11562 (http://notmuchmail.org) Emacs/23.2.1\r
40         (i486-pc-linux-gnu)\r
41 Date: Tue, 14 Feb 2012 12:28:48 +0000\r
42 Message-ID: <87haytbnun.fsf@qmul.ac.uk>\r
43 MIME-Version: 1.0\r
44 Content-Type: text/plain; charset=us-ascii\r
45 X-Sender-Host-Address: 94.192.233.223\r
46 X-QM-SPAM-Info: Sender has good ham record.  :)\r
47 X-QM-Body-MD5: e60b2b6677e15dcdacee110fbbe5bbb5 (of first 20000 bytes)\r
48 X-SpamAssassin-Score: -1.8\r
49 X-SpamAssassin-SpamBar: -\r
50 X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
51         determine if it is\r
52         spam. We require at least 5.0 points to mark a message as spam.\r
53         This message scored -1.8 points.\r
54         Summary of the scoring: \r
55         * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\r
56         *      medium trust\r
57         *      [138.37.6.40 listed in list.dnswl.org]\r
58         * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
59         provider *      (markwalters1009[at]gmail.com)\r
60         * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay\r
61         *      domain\r
62         *  0.5 AWL AWL: From: address is in the auto white-list\r
63 X-QM-Scan-Virus: ClamAV says the message is clean\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: Tue, 14 Feb 2012 12:27:30 -0000\r
77 \r
78 \r
79 I have now done some benchmarking/profiling of the notmuch-pick\r
80 mode. These are all done running locally (i.e., no ssh, nfs or anything)\r
81 but on a fairly old computer with a slow hard disk. The timings given\r
82 are for the second run (so the files and database are in cache).\r
83 \r
84 The profiling is done by inserting (message "%s" (current-time)) at\r
85 various points.\r
86 \r
87 For displaying the thread structure of the whole notmuch mailing list\r
88 archive (circa 10,000 messages) it takes about 18 seconds which breaks\r
89 down as 6.5 seconds for the cli part, 9.5 seconds for the json parsing\r
90 in emacs and 1.5 seconds for constructing the thread structure and\r
91 writing the buffer in emacs.\r
92 \r
93 Using Austin's optimised json.el (id:"20110720205007.GB21316@mit.edu")\r
94 the 9.5 seconds reduces to about 2.5 seconds (so the total reduces to\r
95 about 10.5 seconds).\r
96 \r
97 I think the 6.5 seconds of command line time involves quite a lot of\r
98 parsing of the message files (to get the headers) and this could\r
99 probably be sped up by storing more of the headers in the database, or\r
100 just not outputting all of them. Removing all of the calls to\r
101 notmuch_message_get_header seems to reduce the 6.5s to about 1.5s\r
102 \r
103 In other cases, though, notmuch-pick is a noticeable speed win: namely\r
104 `picking' is faster than `showing' for longer threads (as one would\r
105 expect since pick only gets the thread structure and one message body\r
106 whereas show gets the thread structure and all messages bodies). So for\r
107 a thread of 170 messages show takes 5 seconds and pick takes less than\r
108 0.5 seconds, and for a thread of 30 messages show takes 600 milliseconds\r
109 and pick takes takes 150 milliseconds.\r
110 \r
111 Finally, if notmuch-pick were able to do work asynchronously (as\r
112 notmuch-search does now) then I think all the speed concerns would go\r
113 away. However, I am not sure how to do incremental json parsing.\r
114 \r
115 Best wishes\r
116 \r
117 Mark\r
118 \r
119 \r