From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/5617 Path: main.gmane.org!not-for-mail From: Jason L Tibbitts III Newsgroups: gmane.emacs.gnus.general Subject: Re: Catching up Mail Groups Date: 20 Mar 1996 00:56:00 -0600 Organization: Blob Shop Programmers Sender: tibbs@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035146196 853 80.91.224.250 (20 Oct 2002 20:36:36 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 20:36:36 +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.3/8.6.9) with SMTP id XAA05950 for ; Tue, 19 Mar 1996 23:20:11 -0800 Original-Received: from sina.hpc.uh.edu (Sina.HPC.UH.EDU [129.7.3.5]) by ifi.uio.no with ESMTP (8.6.11/ifi2.4) id for ; Wed, 20 Mar 1996 07:56:16 +0100 Original-Received: (from tibbs@localhost) by sina.hpc.uh.edu (8.7.3/8.7.3) id AAA10659; Wed, 20 Mar 1996 00:56:17 -0600 (CST) Original-To: ding@ifi.uio.no In-Reply-To: aharon@healdb.matat.health.gov.il's message of 20 Mar 1996 07:39:53 +0300 Original-Lines: 33 Xref: main.gmane.org gmane.emacs.gnus.general:5617 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:5617 >>>>> "AS" == Aharon (Al) Schkolnik writes: AS> What I, and I believe many others, want is for articles in mail groups AS> which are not marked to be saved (u command), and which are read or AS> deleted, to be deleted after the expiration period. I guess what this AS> all means is that we want deletion (or whatever is done by catching-up, AS> the d command, etc.) to be treated as expiration. This is exactly, positively, 100% what total-expire does. Every message that is killed, deleted or caught-up is deleted after the delay you set (default 28 days). Now, if I'm not mistaken, Gnus has to stat the files (nnml) to see if they should go away. This could, perhaps, be made more efficient by storing some kind of age of each article somewhere so that the stat doesn't get done. I don't know what Gnus has to do to expire things in an nnfolder group; I suspect it's a pile of region deletions which causes a bunch of buffer gap movement and VM thrashing. But then, nnfolder isn't very good for big folders. Myself, I'm drooling over the prospect of nngdbm. BTW, on a large nnml group (~1000 articles) with 28 day expiry it takes about three seconds to do the expiry if the disk is local to the machine. This goes up dramatically if I'm on an NFS mounted volume, even when the interconnect is our 1+Gbit network. NFS sucks for this kind of thing. AS> Of course, this must be efficient. That's just the problem, isn't it? It's kind of difficult to say where the bottleneck is since you don't provide any information at all about your environment, how many articles you're looking at or what backends you're using. Perhaps with a little more information we could give you some optimization tips. - J<