Xref: utzoo news.software.b:7611 comp.unix.sysv386:7514 comp.unix.xenix.sco:2376 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!ukc!stc!stl!robobar!ronald From: ronald@robobar.co.uk (Ronald S H Khoo) Newsgroups: news.software.b,comp.unix.sysv386,comp.unix.xenix.sco Subject: Re: C-news and SCO Xenix 2.3.3 Keywords: slow relaynews Message-ID: <1991Apr29.160721.1854@robobar.co.uk> Date: 29 Apr 91 16:07:21 GMT References: <1991Apr24.030223.7753@DSI.COM> Followup-To: news.software.b Organization: Robobar Ltd., Perivale, Middx., ENGLAND. Lines: 28 [ discussion widened, because it's generally relevant. please edit followups ] syd@DSI.COM writes: > Finally had time to track down a problem with C News and SCO Xenix 2.3.3. This problem is probably far more generic than it wants to be. The strchr in all the SCO development systems I have to hand is the same (that's versions 2.2.0b 2.3.0d 2.3.1b 3.2.0f) and is an assembly coded version of (approximately) char *strchr(char *s, c) { return memchr(s, c, strlen(s)); } This is only slower than Henry's fake where the match is significantly earlier than the length of the string, and this is only of material consequence[*] in that single strchr in active.fast.c. Unfortunately, I have seen this algorithm for strchr in other places, especially where memchr() is fast. So, if relaynews takes more than a second or so to run for a single article, this is worth examining, I guess. Sigh. Geoff & Syd: Matthew's CPU thanks you -- it was running out of cycles. ------ [*] as far as relaynews is concerned, anyway. -- Ronald Khoo +44 81 991 1142 (O) +44 71 229 7741 (H)