Path: utzoo!utstat!helios.physics.utoronto.ca!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!samsung!umich!umeecs!itivax!b-tech!zeeff From: zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) Newsgroups: news.software.b Subject: Re: Is there a way to control the time when news is unpacked? Message-ID: <-RV#65=@b-tech.uucp> Date: 21 Feb 90 15:35:15 GMT References: <239@cmic.UUCP> <1309@ispi.UUCP> <3273@caesar.cs.montana.edu> <1990Feb19.175403.8006@utzoo.uucp> <1990Feb20.164346.6246@utzoo.uucp> Organization: Branch Technology Lines: 23 >>>... standard with C News. If you want to pay the extra costs of doing >>>an unpacking immediately (it does cost a little extra, it turns out), >>>you have to work at it. >> >>I agree, if you use the standard C News method... > >Jon, it costs a little extra no matter how you do it; amortizing startup >and shutdown overhead over multiple batches is a win even when those >overheads are small. I'm not sure I agree. A process (rnews) is already running and if you are going to delay processing and do it in a batch, you have to copy the news off somewhere (which adds disk i/o overhead) and then start up another process to handle it later. It's also suprising how little processing doesn't get repeated for every batch - looking at newsrun, all I see if a few lines of minor code (like a lock creation and a hostname determination) that aren't in the main loop. Plus, my rnews is faster than either of the C News methods, meaning that while in theory you might be able to gain something (what?) by doing it in batches, in practice you can't (with currently available code). -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us or b-tech!zeeff