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