Many operations in the Gnus news/mail reader are slow (and also slower than other mail clients). This page wants to make Gnus faster, and lists the common sources of waiting, the reasons of the slowness, the final solutions to quicken Gnus and the practical tips and tricks against Gnus’ slowness.
Please expand this page with more technical content from experts.
List and discuss them here.
… TODO: write
Gnus is by design synchronous. You enter a group, then wait for the summary buffer to be built. Gnus doesn’t have the concept of “enter a buffer and let the articles come in asynchronously”. Gnus blocks on many other operations too.
A mail with a 10 Mb attachment must be completely downloaded. IMAP supports downloading any part of a MIME message individually, but Gnus doesn’t implement this (as of August 2009).
There is no variable which says „only download attachments when I ask you to“. IMAP is the only storage format which provides an API to the MIME structure, and is relatively new Gnus.
The current Gnus development version has this functionality. Have a look at the variable
A big win would be obtained if Gnus could run in other thread; at least it wouldn’t block all Emacs. This needs some multithreading support from Emacs Lisp. See ConcurrentEmacs.
Maybe some parts could be delegated to another process? Maybe written in another language
See ConcurrentEmacs. This solution requires rewriting Emacs to add support for threads. That, in turn, would require rebuilding the Emacs Lisp engine to support concurrency, which can be very complex because a completely dynamically scoped language doesn’t play nicely with threads.
But this may mean to rewrite Gnus’ core. Hey, this can be a good thing in the end.
You can notice that even opening a new Emacs instance takes very little time:
$ time emacs -Q --batch --eval '(message "this is another Emacs %i instance" (+ 20 3))' this is another Emacs 23 instance real 0m0.053s user 0m0.028s sys 0m0.024s
So why not delegate some tasks to another process?
If you see a message like this in your Messages buffer
Opening TLS connection with `gnutls-cli --insecure -p 993 imap.gmail.com’…failed
that means gnutls-cli is not installed (the case of Ubuntu)
Install it and you will gain preciouscouple of seconds on startup.
There are many variables like gnus-asynchronous. Can they make a difference if set to true?
Does the gnus-agent improve Gnus’s speed for all groups?
Adaptive scoring can use a lot of space and maybe affect speed. The variable gnus-use-adaptive-scoring (nil by default) controls whether to use it.
Some people suggest omitting scoring completely for maximum speed. Others don’t notice any speed penalty, or find scoring too valuable to ignore.
Scoring can be slow if you do it against the full head or body because Gnus has to request much data. See this example with timings. Scoring basic headers like to/from/subject should be faster.
An alternative to search inside the body is to use keywords; see description.
You can prohibit scoring in headers or body via the variable gnus-inhibit-slow-scoring; for instance if it is set to “^nntp[+:]”
E.g. use offlineimap (an IMAP synchronization tool) to pull emails from a remote server instead of connecting directly to GnusGmail, for instance. Several Gnus users run a local IMAP server, such as dovecot, which they synchronize using offlineimap and access from Gnus via nnimap.
Other option: use fetchmail+maildrop to get mails and deliver to local Maildir, then use nnmaildir to read mails.
If you are running debian (or a derivative) and you use exim4 for smtp delivery with a smarthost, add the option ‘-odqs’ in /etc/default/exim4 SMTPLISTENEROPTIONS (otherwise gnus still locks up your emacs when sending large attachments). Also change QUEUEINTERVAL to something smaller like 5m. If you need a message sent immediately run sudo exim4 -q.
$WGET -q ‘http://planet.emacsen.org/atom.xml’ -O - | xsltproc -o “$RSSDIR”/’Planet\ Emacs.xml’ ~/.emacs.d/atom2rss-exslt.xsl -
If you use shimbuns, there’s ‘shimbun-use-local’ and ‘nnshimbun-generate-download-script’ which do the same.
The following can be used to update automatically the shimbun script created by nnshimbun-generate-download-script (useful if one has added or removed shimbun groups in Gnus):
(defun my-nnshimbun-generate-download-script () (nnshimbun-generate-download-script) (write-file "~/bin/nnshimbun.sh") (kill-buffer nil) (shell-command "chmod u+x ~/bin/nnshimbun.sh") (message "Nnshimbun script saved."))
(add-hook 'gnus-exit-gnus-hook 'my-nnshimbun-generate-download-script)
Note: such a hook does not work so well with nnrss-generate-download-script, which populates the script only with nnrss groups that have been updated in the current session of Gnus (as opposed to all subscribed rss groups).
Many people end up opening two Emacs processes: one for editing, other for Gnus. In this way, even if Gnus blocks, the editing Emacs is responsive. You lose however the integration; it will be more cumbersome to pass stuff around stuff (bookmarks, org-mode, Lisp code.) and you will have to maintain 2 configurations. It isn’t anymore *1 Emacs to rule them all*, they are 2.