From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/8105 Path: main.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.gnus.general Subject: Re: Long time to exit summary buffer, possible speed enhancement? Date: 29 Sep 1996 05:50:33 -0400 Sender: raeburn@cygnus.com Message-ID: References: <199609272028.PAA08122@mordor.rsn.hp.com> NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035148320 10129 80.91.224.250 (20 Oct 2002 21:12:00 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:12:00 +0000 (UTC) Return-Path: ding-request@ifi.uio.no Original-Received: from ifi.uio.no (ifi.uio.no [129.240.64.2]) by deanna.miranova.com (8.7.6/8.6.9) with SMTP id DAA23734 for ; Sun, 29 Sep 1996 03:14:14 -0700 Original-Received: from cygnus.com (cygnus.com [140.174.1.1]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Sun, 29 Sep 1996 11:51:37 +0200 Original-Received: from tweedledumb.cygnus.com (tweedledumb.cygnus.com [192.80.44.1]) by cygnus.com (8.6.12/8.6.9) with SMTP id CAA14783; Sun, 29 Sep 1996 02:51:00 -0700 Original-Received: from kr-laptop.cygnus.com by tweedledumb.cygnus.com (4.1/4.7) id AA15692; Sun, 29 Sep 96 05:50:37 EDT Original-Received: (from raeburn@localhost) by kr-laptop.cygnus.com (8.7.5/8.7.3) id FAA17002; Sun, 29 Sep 1996 05:50:34 -0400 Original-To: ding@ifi.uio.no In-Reply-To: Lars Magne Ingebrigtsen's message of 28 Sep 1996 22:08:18 +0200 Original-Lines: 41 X-Mailer: Red Gnus v0.45/Emacs 19.34 Xref: main.gmane.org gmane.emacs.gnus.general:8105 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:8105 Lars Magne Ingebrigtsen writes: > Shane Holder 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