Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!bfmny0!tneff
From: tneff@bfmny0.UU.NET (Tom Neff)
Newsgroups: news.software.b
Subject: Re: B news problems
Message-ID: <14728@bfmny0.UU.NET>
Date: 25 Sep 89 13:58:58 GMT
References: <366@jwt.UUCP>
Reply-To: tneff@bfmny0.UU.NET (Tom Neff)
Organization: ^
Lines: 19
Summary:
Expires:
Sender:
Followup-To:

In article <366@jwt.UUCP> john@jwt.UUCP (John Temples) writes:
>The new problem introduced with 2.11.18 has to do with the speed of
>news unbatching.  It's now taking 2-3 times as long to unbatch news.
>Under 2.11.14, my disk lights would stay on continuously until
>unbatching was done.  Now, it looks like it's unbatching an article,
>sleeping three or four seconds, then doing another article.  Has anyone
>else noticed this?

I have seen somewhat lengthy processing times, seemingly dependent
on the *length* of the articles being fed to rnews.  For instance
the recent "Elk" 14-part source in comp.sources.misc (I don't know
about the rest of you, but an 800k Scheme interpreter is exactly
what *I* was looking for!) took an agonizingly long time to spool
each article.  (It wasn't the uncompress either -- that only takes
a couple of seconds for 30k->60k.)  I assume we're checking for
something now, but I'm not sure.
-- 
"Take off your engineering hat   | "The filter has      | Tom Neff
and put on your management hat." | discreting sources." | tneff@bfmny0.UU.NET