Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!brl-adm!seismo!ll-xn!ames!ucbcad!ucbvax!amdcad!rpw3
From: rpw3@amdcad.UUCP
Newsgroups: comp.arch,comp.lang.c
Subject: Re: String Processing Instruction
Message-ID: <15317@amdcad.UUCP>
Date: Sat, 28-Mar-87 01:07:59 EST
Article-I.D.: amdcad.15317
Posted: Sat Mar 28 01:07:59 1987
Date-Received: Sat, 28-Mar-87 18:19:57 EST
References: <15292@amdcad.UUCP> <978@ames.UUCP> <15304@amdcad.UUCP> <232@winchester.mips.UUCP>
Reply-To: rpw3@amdcad.UUCP (Rob Warnock)
Distribution: na
Organization: [Consultant] San Mateo, CA
Lines: 53
Keywords: strlen strcmp strcpy
Xref: utgpu comp.arch:687 comp.lang.c:1361
Summary: Look at the history of old code versus new code.

Well, John Mashey's numbers were certainly counter-intuitive to ME, given
that those programs bang away at characters all the time, but we should
look at one more thing:

When were nroff/grep/yacc written compared to when str* was standardized
in the library? After all, the str* libraries didn't spring full-blown on
day one with those exact sematics and calling sequences (I'm guessing).
I'll also guess (could easily be wrong) that there is a lot more string
stuff going on than you see in the str* statistics, and that it's hand
coded "in line" (in C, of course).

Counter point: What do similar NEW programs look like? Take some code
written by someone (or a team) that started with the "modern" libraries.
Run the statistics on that, and see...

Finally, don't forget str{,r}chr (a.k.a. {,r}index). Things like "ls -l"
beat on those really hard (at least in System-V), since way down at the
bottom a lot of time is spent (I'm guessing) tearing apart /etc/passwd
entries (go look at "getpwent" & friends).

I know that I sometimes avoid str* because I'm afraid it might be slow,
particularly when I know that keeping a count (a.k.a. length) can avoid
a lot of searching for the end. The solution is usually a high-level change
in the applications basic algorithms so that so much copying & searching
is simply avoided. A simple example is when you are building various
strings up out of pieces (as in "speeding up" shell scripts by recoding
in C). Even USING the libraries, sometimes instead of:

	strcpy(buf, "piece");
	strcat(buf, "another piece");
	strcat(buf, "still another piece");

I find myself doing:

	char *p = &buf[0];
	int n;

	strcpy(p, "piece");		p += strlen(p);
	strcpy(p, "another piece");	p += strlen(p);
	sprintf(p, "format%d%s", args...); p+= strlen(p);
	strcpy(p, "still another piece"); p += strlen(p);
	etc...

Then when you're done, you can assert that strlen(buf) == (p - buf);


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun,attmail}!redwood!rpw3
ATTmail:  !rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403