On Sat, 05 Dec 2009 15:10:18 -0800, Alexander Botero-Lowry <alex.boterolowry at gmail.com> wrote: > Carl mentioned that he saw some nasty performance issues with threads > that had a lot of HTML messages in them. > > If you are experiencing this problem, would you mind trying some > alternative mm-text-html-renderer setting: > > http://mh-e.sourceforge.net/manual/html/HTML.html > > Also, if you have elinks, I recommend my custom renderer: > > (require 'mm-view) > (add-to-list 'mm-text-html-renderer-alist > '(elinks mm-inline-render-with-stdin nil "elinks" "-force-html" "-dump")) > (setq mm-text-html-renderer 'elinks)
Hi Alex, I'm sorry, but the delays got in my way so much this morning that I reverted the patch before even attempting the alternate renderer. Part of my annoyance may have been due to a distinct bug. There was definitely one instance where I was seeing a big delay when trying to display a tiny thread (about 13 messages) none of which were HTML. I reverted the HTML-rendering patch and saw the delay go away, but I also put the patch back and didn't see the problem come back. So that problem might have been form something else. But when I looked at the patch and saw that it was doing this: - (let ((filename (notmuch-show-get-filename))) - (with-temp-buffer - (insert-file-contents filename nil nil nil t) for every file, (regardless of it being HTML or not), I was convinced that there's got to be a better way. Notmuch has already passed the entire thread through GMime, so we really don't want to do a second pass of all of the raw message content through an emacs-lisp MIME parser as well. Instead, let's find a way to just get the information from GMime to be cheaply available for emacs to look at (without loading all of the original files). -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20091207/e79b727c/attachment.pgp>
