Xref: utzoo comp.sources.d:1742 news.software.b:1084
Path: utzoo!mnetor!uunet!husc6!cmcl2!beta!hc!ames!elroy!devvax!lwall
From: lwall@devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.sources.d,news.software.b
Subject: Re: rn kill file status display efficiency
Message-ID: <1170@devvax.JPL.NASA.GOV>
Date: 28 Jan 88 16:17:35 GMT
References: <5365@tut.cis.ohio-state.edu> <1117@hao.ucar.edu>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA.
Lines: 22

In article <1117@hao.ucar.edu> woods@hao.UUCP (Greg Woods) writes:
: In article <5365@tut.cis.ohio-state.edu> bob@tut.cis.ohio-state.edu (Bob Sutterfield) writes:
: >How can I encourage rn to count how many articles have been killed so
: >far, and if that matches the number of unread articles it saw when I
: >started that newsgroup, I should go on to the next group without
: >bothering to check all the rest of the kill file?
: 
:    My observation of how rn works is that the first line in the KILL file
: takes a while to process, while all the subject lines of unread articles
: are read in. However, checking each additional line is a relatively fast
: process since all the article files do not have to be reopened to do this.
: I think you are worrying about something that is a relatively minor slowdown.

This is true, as long as you haven't undefined SUBJCACHE to save memory.

In the new version of rn, if I ever get a chance to finish it, kill processing
is done in a lookahead fashion so that you don't have to wait.  Also, all
patterns are applied to each article, rather than each pattern applied to all
articles, so the aforementioned situation never arises.

Larry Wall
lwall@jpl-devvax.jpl.nasa.gov