From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/24054 Path: main.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Fran=E7ois_Pinard?= Newsgroups: gmane.emacs.gnus.general Subject: Re: Holes in article sequence Date: 09 Jul 1999 13:25:52 -0400 Sender: owner-ding@hpc.uh.edu Message-ID: References: <874sjhjitm.fsf@pc-hrvoje.srce.hr> 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 1035161688 6632 80.91.224.250 (21 Oct 2002 00:54:48 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 00:54:48 +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 NAA22931 for ; Fri, 9 Jul 1999 13:27:46 -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 MAB21456; Fri, 9 Jul 1999 12:27:35 -0500 (CDT) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 09 Jul 1999 12:28:26 -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 MAA13501 for ; Fri, 9 Jul 1999 12:28:15 -0500 (CDT) Original-Received: from jupiter.rtsq.qc.ca (rtsq.grics.qc.ca [199.84.132.81]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id NAA22924 for ; Fri, 9 Jul 1999 13:27:11 -0400 (EDT) Original-Received: from ariel.progiciels-bpi.ca by jupiter.rtsq.qc.ca (8.8.8/8.8.8) with SMTP id NAA22715 for <@jupiter.rtsq.qc.ca:ding@gnus.org>; Fri, 9 Jul 1999 13:26:40 -0400 Original-Received: from iro.umontreal.ca (uucp@localhost) by ariel.progiciels-bpi.ca (950413.SGI.8.6.12/950213.SGI) via UUCP id NAA12156 for ding@gnus.org; Fri, 9 Jul 1999 13:29:37 -0700 Original-Received: from titan.progiciels-bpi.ca.progiciels-bpi.ca by icule.progiciels-bpi.ca (8.8.8/8.8.8) with ESMTP id NAA02081; Fri, 9 Jul 1999 13:25:58 -0400 Original-To: ding@gnus.org X-Face: "b_m|CE6#'Q8fliQrwHl9K,]PA_o'*S~Dva{~b1n*)K*A(BIwQW.:LY?t4~xhYka_.LV?Qq `}X|71X0ea&H]9Dsk!`kxBXlG;q$mLfv_vtaHK_rHFKu]4'<*LWCyUe@ZcI6"*wB5M@[m writes: > Hrvoje Niksic writes: > > 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. > One could speed things up by having the backend look at what articles > exist in the group, and then iterate over that instead of the other > way around. That would be much, much quicker for groups with big > "holes" in them. It might be slower in other situations, though. If this is the only problem with big holes, it would be worth moving iterating the other way around, and forget hole problems forever :-). If you fear that it could a bit slow, but are able to keep the old code as well as the new, maybe you could let the number of articles decide which method to use, or else, have some collaboration from the backend to tell you when it is better to change methods. Or maybe both: if the backend has nothing to say, use some heuristic on the number of articles. Of course, if the other-way-around is not supported by the backend, just use the old way. -- François Pinard http://www.iro.umontreal.ca/~pinard