Re: Long time to exit summary buffer, possible speed enhancement?

[Ken Raeburn <raeburn@cygnus.com>]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> Shane Holder <holder@mordor.rsn.hp.com> writes:
> > When I try to exit my mail group, it takes a longer than I think it
> > should ~10 seconds.  There is nothing to expire, nothing that gnus
> > should do.  I think part of the problem is that my list of articles is
> > pretty big, and maybe larger than it needs to be.
 ...
> Anyways, range handling isn't all that slow, so the ~10 second delay
> probably is caused by something else.  Try `(setq debug-on-quit t)'
> and then `C-g' when things "hang" (sorta).  The resulting backtrace
> should tell you which function is being slow.

Check for sparse article numbers.  I've got some nnml groups where I've
ticked some old articles and read (and thus deleted) lots of others with
higher numbers.  When I check the backtrace as Lars suggests, I find
most of the time is spent in the request-expire loop, checking article
numbers where all traces of the article have long since been deleted.
For example, if you've ticked article 100, and deleted 101-199 months
ago, it'll still check 101-199 to see if they exist.  I think I brought
this up before, during or maybe after the September development cycle.

A hack workaround to this is to move all the articles (mark everything
with `#', then hit `B m') from the mail group to that same mail group,
which causes sequential renumbering and thus removes the empty ranges.
Unfortunately, it also discards any xref info if those messages were
also stored in other mail groups.  And it's only a temporary fix.

If there's no info on an article in the overview, I don't see the point
in checking for the file on disk.

Another lament for the lack of multi-threaded elisp: The expiration
ought to be done in background after exiting the group, at a lower
priority than redisplay and user input processing, and probably async
article prefetching.  Just because it takes a while to stat and maybe
delete a few hundred existing article files (even after the above
sparse-numbering problem is fixed) doesn't mean I should have to wait
before I can start reading from the next group.  Something could
probably be thrown together to use idle cycles for this...

Ken