I have now done some benchmarking/profiling of the notmuch-pick
mode. These are all done running locally (i.e., no ssh, nfs or anything)
but on a fairly old computer with a slow hard disk. The timings given
are for the second run (so the files and database are in cache).

The profiling is done by inserting (message "%s" (current-time)) at
various points.

For displaying the thread structure of the whole notmuch mailing list
archive (circa 10,000 messages) it takes about 18 seconds which breaks
down as 6.5 seconds for the cli part, 9.5 seconds for the json parsing
in emacs and 1.5 seconds for constructing the thread structure and
writing the buffer in emacs.

Using Austin's optimised json.el (id:"20110720205007.GB21316@mit.edu")
the 9.5 seconds reduces to about 2.5 seconds (so the total reduces to
about 10.5 seconds).

I think the 6.5 seconds of command line time involves quite a lot of
parsing of the message files (to get the headers) and this could
probably be sped up by storing more of the headers in the database, or
just not outputting all of them. Removing all of the calls to
notmuch_message_get_header seems to reduce the 6.5s to about 1.5s

In other cases, though, notmuch-pick is a noticeable speed win: namely
`picking' is faster than `showing' for longer threads (as one would
expect since pick only gets the thread structure and one message body
whereas show gets the thread structure and all messages bodies). So for
a thread of 170 messages show takes 5 seconds and pick takes less than
0.5 seconds, and for a thread of 30 messages show takes 600 milliseconds
and pick takes takes 150 milliseconds.

Finally, if notmuch-pick were able to do work asynchronously (as
notmuch-search does now) then I think all the speed concerns would go
away. However, I am not sure how to do incremental json parsing.

Best wishes

Mark