* 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).