From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/8106 Path: main.gmane.org!not-for-mail From: Hallvard B Furuseth Newsgroups: gmane.emacs.gnus.general Subject: Re: Long time to exit summary buffer, possible speed enhancement? Date: Sun, 29 Sep 1996 14:09:23 +0100 (MET) Message-ID: <199609291309.OAA29461@gandalf.uio.no> References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035148321 10137 80.91.224.250 (20 Oct 2002 21:12:01 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 21:12:01 +0000 (UTC) Cc: ding@ifi.uio.no 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 GAA23874 for ; Sun, 29 Sep 1996 06:24:02 -0700 Original-Received: from goggins.uio.no (6089@goggins.uio.no [129.240.201.2]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) id ; Sun, 29 Sep 1996 15:09:40 +0200 Original-Received: from ulrik.uio.no by goggins.uio.no with local-SMTP (PP) id <24918-0@goggins.uio.no>; Sun, 29 Sep 1996 14:09:25 +0100 Original-Received: by gandalf.uio.no ; Sun, 29 Sep 1996 14:09:23 +0100 (MET) Original-To: Lars Magne Ingebrigtsen In-reply-to: Xref: main.gmane.org gmane.emacs.gnus.general:8106 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:8106 Lars Magne Ingebrigtsen writes: >Shane Holder writes: > >> Would it be possible to make gnus understand that if an >> article doesnt exist that it can collapse the range? > > Well, it can't -- then the range would be incorrect, wouldn't it? Why, no. Articles get increasing numbers as they arrive. They will not not interleave. Hmm - except if the article number wraps around. That can happen, right? So *big* holes in ranges must not be collapsed since new articles may be arriving at the beginning of the hole. Instead, nonexisting article numbers should be removed from the beginning of a range following a big hole, to make room for new articles. Lars Magne Ingebrigtsen writes: > 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. Ken Raeburn writes: > 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. Besides, you can't do that with news articles. An old news article will be followed by a *huge* hole in a newsgroup with high voloume and rapid expiry, if it is crossposted to a group with slow expiry or if it has an Expires: header which makes it stay around for some time. Regards, Hallvard