GNU bug report logs - #50877
28.0.50; Gnus: nnimap backend is extremely slow to initialise new groups

Previous Next

Full log

Message #8 received at 50877 <at> debbugs.gnu.org (full text, mbox):

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Morgan Willcock <mwillcock <at> precedence.co.uk>
Cc: 50877 <at> debbugs.gnu.org
Subject: Re: bug#50877: 28.0.50; Gnus: nnimap backend is extremely slow to
 initialise new groups
Date: Tue, 28 Sep 2021 14:34:05 -0700

Morgan Willcock <mwillcock <at> precedence.co.uk> writes:

> It seems that the nnimap backend in Emacs 28 is now extremely slow to
> initialise.
>
> The initialisation first downloads 10MB of data from the IMAP server:
>
>   nnimap read 10219k from server (initial sync of 16 groups; please wait)
>
> Once all data is downloaded Emacs 27 takes 2 or 3 seconds to process the
> data and display the group buffer whereas Emacs 28 takes 5 minutes 30
> seconds for the same data. CPU usage is at 100% for this time. The time
> taken is long enough that I've repeatedly thought the nnimap backend was
> broken in Emacs 28.
>
> To recreate with emacs -Q all I am doing is removing all local news
> files:
>
>   rm ~/.newsrc*
>
> ...and then configuring the bare minimum for Gnus to use nnimap:
>
>   ;; No primary server
>   (setq gnus-select-method '(nnnil ""))
>
>   ;; IMAP as a secondary
>   (setq gnus-secondary-select-methods
>         '((nnimap "company"
>                   (nnimap-address "server")
>                   (nnimap-server-port "imap")
>                   (nnimap-stream plain))))
>
> I imagine this problem is only going to show where mailbox sizes are
> fairly large (this example is 10MB of headers not 10MB of e-mail). Using
> the option to debug-on-quit it seems that I always interupt somewhere
> inside `seq-difference' inside of `nnimap-update-info':

You could try reverting 20f7fa691b7c2859b96550d9ccb326bf394e160d and see
if that fixes it. That change went in in April, though, so unless you
haven't updated for a while (or you've been seeing this problem for a
long time) it might not be likely.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.