[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#50877: 28.0.50; Gnus: nnimap backend is extremely slow to initialise
From: |
Eric Abrahamsen |
Subject: |
bug#50877: 28.0.50; Gnus: nnimap backend is extremely slow to initialise new groups |
Date: |
Tue, 28 Sep 2021 14:34:05 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Morgan Willcock <mwillcock@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.