From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/23944
Path: main.gmane.org!not-for-mail
From: =?ISO-8859-1?Q?Fran=E7ois_Pinard?= <pinard@iro.umontreal.ca>
Newsgroups: gmane.emacs.gnus.general
Subject: Holes in article sequence
Date: 06 Jul 1999 21:13:18 -0400
Sender: owner-ding@hpc.uh.edu
Message-ID: <oqyagt9s9d.fsf@titan.progiciels-bpi.ca>
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 1035161584 5962 80.91.224.250 (21 Oct 2002 00:53:04 GMT)
X-Complaints-To: usenet@main.gmane.org
NNTP-Posting-Date: Mon, 21 Oct 2002 00:53:04 +0000 (UTC)
Return-Path: <owner-ding@hpc.uh.edu>
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 UAA18438
	for <jason@mailhost.sclp.com>; Tue, 6 Jul 1999 20:57:07 -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 TAB22303;
	Tue, 6 Jul 1999 19:56:53 -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 19:57:44 -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 TAA01039
	for <ding@hpc.uh.edu>; Tue, 6 Jul 1999 19:57:34 -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 UAA18423
	for <ding@gnus.org>; Tue, 6 Jul 1999 20:56:33 -0400 (EDT)
Original-Received: from ariel.progiciels-bpi.ca by jupiter.rtsq.qc.ca (8.8.8/8.8.8) with SMTP id UAA15056 for <@jupiter.rtsq.qc.ca:ding@gnus.org>; Tue, 6 Jul 1999 20:56:03 -0400
Original-Received: from iro.umontreal.ca (uucp@localhost) by ariel.progiciels-bpi.ca (950413.SGI.8.6.12/950213.SGI) via UUCP id UAA03716 for ding@gnus.org; Tue, 6 Jul 1999 20:58:56 -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 UAA03018; Tue, 6 Jul 1999 20:55:22 -0400
Original-To: Forum of ding/Gnus users <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<Ok5/cC^=
 CxDhg=TJi^o[E
Original-Lines: 16
Precedence: list
X-Majordomo: 1.94.jlt7
X-MIME-Autoconverted: from quoted-printable to 8bit by sclp3.sclp.com id UAA18438
Xref: main.gmane.org gmane.emacs.gnus.general:23944
X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:23944

Hi, people.

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?

Is it backend dependent, or not?  Do those inefficiencies exist for `nnml'
in particular?  Is this an I/O related problem?  Do the particular holes at
both end generate inefficiencies?  For example, if I am revisiting a group
I did not see for a long while, will there be an extra inefficiency for
the size of the hole, besides the fact I have many articles to catchup?
Would the problem be merely related to the fact that Gnus expands lists
in memory instead of keeping them in interval form?

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard