From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/23947 Path: main.gmane.org!not-for-mail From: Hrvoje Niksic Newsgroups: gmane.emacs.gnus.general Subject: Re: Holes in article sequence Date: 07 Jul 1999 04:27:01 +0200 Sender: owner-ding@hpc.uh.edu Message-ID: <874sjhjitm.fsf@pc-hrvoje.srce.hr> References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1035161586 5973 80.91.224.250 (21 Oct 2002 00:53:06 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 00:53:06 +0000 (UTC) Return-Path: Original-Received: from farabi.math.uh.edu (farabi.math.uh.edu [129.7.128.57]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id WAA20480 for ; Tue, 6 Jul 1999 22:27:52 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by farabi.math.uh.edu (8.9.1/8.9.1) with ESMTP id VAB23212; Tue, 6 Jul 1999 21:27:36 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 06 Jul 1999 21:28:23 -0500 (CDT) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.9.3/8.9.3) with ESMTP id VAA01621 for ; Tue, 6 Jul 1999 21:28:12 -0500 (CDT) Original-Received: from pc-hrvoje.srce.hr (mail@pc-hrvoje.srce.hr [161.53.2.132]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id WAA20453 for ; Tue, 6 Jul 1999 22:27:08 -0400 (EDT) Original-Received: from hniksic by pc-hrvoje.srce.hr with local (Exim 3.02 #1 (Debian)) id 111hQL-00005A-00 for ; Wed, 07 Jul 1999 04:27:01 +0200 Original-To: ding@gnus.org X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h writes: > I've often seen complaints about inefficiencies induced by big holes > in the sequence of read article numbers, but I do not know the deep > reason behind such inefficiencies. Would someone accept to > enlighten me? The one inefficiency I know of is when you use total-expiry and nnml. Because of the way total expiry works, Gnus has to stat all the files in the article range, and delete the ones that should be deleted (usually those older than N days.) Now, if you have a big hole in your article range -- e.g. your article range is 128 - 12300 because you ticked article no. 128 -- total expiry will stat tens of thousands of non-existant files every time you leave the group. That tends to get a bit slow. The correct solution would be to expand Gnus' concept of "active range" to be a list of ranges instead of a single range. Then total-expiry could work sanely. David Moore had interesting ideas about this, but he disappeared before doing anything.