Newsgroups: news.admin Path: utzoo!utstat!geoff From: geoff@utstat.uucp (Geoff Collyer) Subject: C inews & rnews speed (was Re: News delivery problems - old news again) Message-ID: <1989Aug9.042147.10335@utstat.uucp> Organization: Statistics, U. of Toronto References: <43675@bbn.COM> <651@vector.Dallas.TX.US> <1989Aug3.180304.6252@eci386.uucp> <653@vector.Dallas.TX.US> <1989Aug7.230146.274@servalan.uucp> Date: Wed, 9 Aug 89 04:21:47 GMT We realise that C inews is slow and have some ideas about how to speed it up. One important property of inews as a shell script is that it should in general be easier to modify to suit local policies than equivalent C code would be. C inews has become large and tricky enough, in part from trying to cope with different Unixes, that I am considering making some of its components C programs, where those components are generally useful and don't imply much about local policy. Richard Todd: > I don't have any good benchmarks on C News vs B News processing of > incoming batches, but it seems to take roughly the same amount of time > to unpack comparably sized batches of news on servalan and on uokmax (a > Multimax running B2.11 News under BSD4.2). If B news doesn't take at least ten times as much elapsed and CPU time as C news to process identical input batches on the same machine, after subtracting uncompress or bdecode or uudecode time, then something is seriously wrong, possibly with your C news configuration. Given the vast amount of disk i/o performed by B rnews, it just isn't possible for B news and properly-configured C news to be even close in running times (if it were, we would still be running B news!). However, posting 300 separate cancellations via inews isn't sensible, under B or C news. The way to cope with 300 cancellations is to generate the articles mechanically as one batch and feed it to relaynews. About the only non-trivial thing inews does it to add a unique Message-ID:, and that may be worth breaking out and reimplementing in C. It still amazes me that people use inews directly at all. > Amazing what you can learn just by reading the documentation :-). Indeed. If we could only get people to read it *before* installing, we would get a lot less mail. ``... users of a tool are willing to meet you halfway; if you do ninety percent of the job, they will be ecstatic.'' - Software Tools, p.136. Please note that we view this as a requirement upon users of our software, not merely an observation. :-) -- Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu