* emacs / vim - time taken to open threads
@ 2015-03-24 21:58 Matthew Lear
2015-03-24 23:10 ` David Bremner
0 siblings, 1 reply; 6+ messages in thread
From: Matthew Lear @ 2015-03-24 21:58 UTC (permalink / raw)
To: notmuch
Hi all,
Continuing my journey with notmuch... It has been very enjoyable so far.
One thing which has been puzzling me greatly is the time it can take to
notmuch-show a moderately sized thread (eg one with 32 messages with a
three to four sentence paragraph per message - approx 32 x 35kB with
some small attachments). Opening the thread using notmuch-show in emacs
takes about six seconds. If I build the ruby bindings and load up
notmuch in vim or gvim, opening the same thread takes less than a
second. It's *loads* quicker.
I've rolled back and rolled forwards the version of emacs in my gentoo
installation (various versions of 24) and built it without all available
options, run it bare bones in X and without X. The behaviour is the
same. I've also stripped back my .emacs to nothing more than pulling in
notmuch.el but there is no change in the behaviour.
I've read some posts about emacs hanging when opening emails due to
attached files, but that was quite a while ago (pre 24). Some of the
emails in my thread have photos (a few hundred kB), others have URLs but
this shouldn't slow emacs down.
Despite being a vi guy for years, I prefer the emacs interface to
notmuch and really like what it provides. I'm sticking with it but there
is clearly a problem and I'd like to solve it. It's annoying when you
know that something isn't working as well as it should be.
Is it known that emacs is slower with notmuch or do you think I have
some kind of build / environment problem? Or could it be due to some of
the email content (doubtful) or something else such as encoding etc?
Cheers,
-- Matt
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: emacs / vim - time taken to open threads
2015-03-24 21:58 emacs / vim - time taken to open threads Matthew Lear
@ 2015-03-24 23:10 ` David Bremner
2015-03-25 7:54 ` Tomi Ollila
0 siblings, 1 reply; 6+ messages in thread
From: David Bremner @ 2015-03-24 23:10 UTC (permalink / raw)
To: Matthew Lear, notmuch
Matthew Lear <matt@bubblegen.co.uk> writes:
>
> Despite being a vi guy for years, I prefer the emacs interface to
> notmuch and really like what it provides. I'm sticking with it but there
> is clearly a problem and I'd like to solve it. It's annoying when you
> know that something isn't working as well as it should be.
>
> Is it known that emacs is slower with notmuch or do you think I have
> some kind of build / environment problem? Or could it be due to some of
> the email content (doubtful) or something else such as encoding etc?
My experience is that the emacs interface is faster than the vim one.
At least I don't have an examples handy where emacs is slower than the
vim interface at rendering a thread. At a wild guess, I suspect it has
to do with how many attachments there are, and the emacs UI being
overenthusiastic about processing attachements.
d
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: emacs / vim - time taken to open threads
2015-03-24 23:10 ` David Bremner
@ 2015-03-25 7:54 ` Tomi Ollila
2015-03-25 11:21 ` Matthew Lear
0 siblings, 1 reply; 6+ messages in thread
From: Tomi Ollila @ 2015-03-25 7:54 UTC (permalink / raw)
To: David Bremner, Matthew Lear, notmuch
On Wed, Mar 25 2015, David Bremner <david@tethera.net> wrote:
> Matthew Lear <matt@bubblegen.co.uk> writes:
>
>>
>> Despite being a vi guy for years, I prefer the emacs interface to
>> notmuch and really like what it provides. I'm sticking with it but there
>> is clearly a problem and I'd like to solve it. It's annoying when you
>> know that something isn't working as well as it should be.
>>
>> Is it known that emacs is slower with notmuch or do you think I have
>> some kind of build / environment problem? Or could it be due to some of
>> the email content (doubtful) or something else such as encoding etc?
>
> My experience is that the emacs interface is faster than the vim one.
> At least I don't have an examples handy where emacs is slower than the
> vim interface at rendering a thread. At a wild guess, I suspect it has
> to do with how many attachments there are, and the emacs UI being
> overenthusiastic about processing attachements.
I've seen over 15 seconds of load time when opening some 20+ message
thread -- and jumping through messages has been slow in emacs ui.
I have not got time to investigate this further...
>
> d
Tomi
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: emacs / vim - time taken to open threads
2015-03-25 7:54 ` Tomi Ollila
@ 2015-03-25 11:21 ` Matthew Lear
2015-04-01 4:08 ` David Bremner
0 siblings, 1 reply; 6+ messages in thread
From: Matthew Lear @ 2015-03-25 11:21 UTC (permalink / raw)
To: Tomi Ollila; +Cc: Matthew Lear, notmuch
[-- Attachment #1: Type: text/plain, Size: 934 bytes --]
>> My experience is that the emacs interface is faster than the vim one.
>> At least I don't have an examples handy where emacs is slower than the
>> vim interface at rendering a thread. At a wild guess, I suspect it has
>> to do with how many attachments there are, and the emacs UI being
>> overenthusiastic about processing attachements.
>
> I've seen over 15 seconds of load time when opening some 20+ message
> thread -- and jumping through messages has been slow in emacs ui.
Here's two attachments obtained using the in-built profiler in emacs 24 -
one for memory profiling and one for cpu. This particular thread took > 30
secs to load and emacs was locked up the entire time. I'm no lisp expert,
but perhaps somebody could interpret this and possible suggest what could
be going on..? W.r.t. both cpu and memory usage, quite a lot of time seems
to be spent in indent-rigidly and notmuch-show-insert-thread.
Cheers,
-- Matt
[-- Attachment #2: cpu.txt --]
[-- Type: text/plain, Size: 0 bytes --]
[-- Attachment #3: mem.txt --]
[-- Type: text/plain, Size: 5259 bytes --]
- command-execute 1,274,239,745 99%
- call-interactively 1,274,239,745 99%
- notmuch-search-show-thread 1,244,222,992 97%
- notmuch-show 1,244,222,992 97%
- notmuch-show-build-buffer 1,244,184,644 97%
- notmuch-show-insert-forest 1,052,295,452 82%
- mapc 1,052,295,452 82%
- #<compiled 0xd784f3> 1,052,295,452 82%
- notmuch-show-insert-thread 1,052,295,452 82%
- mapc 1,052,295,452 82%
- #<compiled 0xd784cd> 1,052,295,452 82%
- notmuch-show-insert-tree 1,052,295,452 82%
- notmuch-show-insert-thread 840,006,831 65%
- mapc 840,006,831 65%
- #<compiled 0xd784cd> 840,006,831 65%
- notmuch-show-insert-tree 840,006,831 65%
- notmuch-show-insert-thread 475,772,280 37%
- mapc 475,772,280 37%
- #<compiled 0xd784cd> 475,772,280 37%
- notmuch-show-insert-tree 475,772,280 37%
- notmuch-show-insert-thread 393,675,698 30%
- mapc 393,675,698 30%
- #<compiled 0xd784cd> 393,675,698 30%
- notmuch-show-insert-tree 393,675,698 30%
- notmuch-show-insert-msg 393,670,578 30%
indent-rigidly 378,976,399 29%
+ notmuch-show-insert-headers 8,573,181 0%
+ notmuch-show-strip-re 38,912 0%
+ notmuch-show-insert-headerline 21,748 0%
+ notmuch-show-message-visible 5,264 0%
notmuch-show-set-message-properties 3,096 0%
make-overlay 1,418 0%
+ notmuch-show-insert-msg 82,096,582 6%
- notmuch-show-insert-msg 364,233,495 28%
+ notmuch-show-insert-body 237,892,232 18%
indent-rigidly 123,850,002 9%
+ notmuch-show-insert-headers 377,077 0%
+ notmuch-show-insert-headerline 85,340 0%
+ notmuch-show-strip-re 20,556 0%
+ notmuch-show-headers-visible 4,208 0%
+ notmuch-show-message-visible 1,056 0%
- notmuch-show-insert-msg 212,283,421 16%
indent-rigidly 155,843,920 12%
+ notmuch-show-insert-body 51,496,368 4%
+ notmuch-show-insert-headers 379,990 0%
+ notmuch-show-insert-headerline 93,694 0%
+ notmuch-show-strip-re 17,802 0%
+ notmuch-show-message-visible 1,056 0%
+ notmuch-show-set-message-properties 1,056 0%
- notmuch-query-get-threads 180,741,671 14%
- apply 180,741,671 14%
- notmuch-call-notmuch-sexp 180,741,671 14%
- notmuch-call-notmuch--helper 175,917,905 13%
apply 175,917,905 13%
+ make-temp-file 101,654 0%
generate-new-buffer 1,029 0%
+ jit-lock-register 11,145,353 0%
+ notmuch-show-strip-re 1,144 0%
replace-regexp-in-string 1,024 0%
+ notmuch-show-goto-first-wanted-message 24,480 0%
+ switch-to-buffer 12,839 0%
+ helm-M-x 29,989,777 2%
+ previous-line 17,280 0%
+ next-line 9,696 0%
+ notmuch-show-command-hook 266,546 0%
+ ... 44,578 0%
- redisplay_internal (C function) 7,648 0%
file-remote-p 5,600 0%
+ kill-this-buffer-enabled-p 2,048 0%
mouse-fixup-help-message 1,024 0%
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: emacs / vim - time taken to open threads
2015-03-25 11:21 ` Matthew Lear
@ 2015-04-01 4:08 ` David Bremner
2015-04-11 18:09 ` Matthew Lear
0 siblings, 1 reply; 6+ messages in thread
From: David Bremner @ 2015-04-01 4:08 UTC (permalink / raw)
To: Matthew Lear; +Cc: notmuch
Matthew Lear <matt@bubblegen.co.uk> writes:
> Here's two attachments obtained using the in-built profiler in emacs 24 -
> one for memory profiling and one for cpu. This particular thread took > 30
> secs to load and emacs was locked up the entire time. I'm no lisp expert,
> but perhaps somebody could interpret this and possible suggest what could
> be going on..? W.r.t. both cpu and memory usage, quite a lot of time seems
> to be spent in indent-rigidly and notmuch-show-insert-thread.
>
That's consistent with what I've seen with very large text attachements.
Can you try the patch
id:1427540939-10055-1-git-send-email-markwalters1009@gmail.com [1]
[1] http://mid.gmane.org/1427540939-10055-1-git-send-email-markwalters1009@gmail.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: emacs / vim - time taken to open threads
2015-04-01 4:08 ` David Bremner
@ 2015-04-11 18:09 ` Matthew Lear
0 siblings, 0 replies; 6+ messages in thread
From: Matthew Lear @ 2015-04-11 18:09 UTC (permalink / raw)
To: David Bremner; +Cc: notmuch
On 01/04/15 05:08, David Bremner wrote:
> Matthew Lear <matt@bubblegen.co.uk> writes:
>
>> Here's two attachments obtained using the in-built profiler in emacs 24 -
>> one for memory profiling and one for cpu. This particular thread took > 30
>> secs to load and emacs was locked up the entire time. I'm no lisp expert,
>> but perhaps somebody could interpret this and possible suggest what could
>> be going on..? W.r.t. both cpu and memory usage, quite a lot of time seems
>> to be spent in indent-rigidly and notmuch-show-insert-thread.
>>
>
> That's consistent with what I've seen with very large text attachements.
> Can you try the patch
>
> id:1427540939-10055-1-git-send-email-markwalters1009@gmail.com [1]
>
> [1] http://mid.gmane.org/1427540939-10055-1-git-send-email-markwalters1009@gmail.com
>
Sorry for the late reply. That has definitely made an improvement.
Opening a large thread takes much less time with the patch applied.
-- Matt
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-04-11 18:21 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-24 21:58 emacs / vim - time taken to open threads Matthew Lear
2015-03-24 23:10 ` David Bremner
2015-03-25 7:54 ` Tomi Ollila
2015-03-25 11:21 ` Matthew Lear
2015-04-01 4:08 ` David Bremner
2015-04-11 18:09 ` Matthew Lear
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).