Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!agate!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Just rambling about optimization...
Message-ID: <13089@dog.ee.lbl.gov>
Date: 11 May 91 13:56:46 GMT
References: <444@smds.UUCP> <186@shasta.Stanford.EDU> <721@taumet.com> <453@smds.UUCP>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 24
X-Local-Date: Sat, 11 May 91 06:56:46 PDT

In article <453@smds.UUCP> rh@smds.UUCP (Richard Harter) writes:
>The point is that optimization of programs frequently involves better
>design of the data management process.

Indeed.  It has been observed (sorry, no references, but this is not
only popularly known but also true :-) ) that many computers spend most
of their time copying data, rather than `computing'.  This is largely
why a fast bcopy/memcpy/memmove is important.  A fast block copy is
a wonderful thing, but better yet is to eliminate the copies altogether.
If the copies are unavoidable, it may pay to compute while copying,
rather than having the sequence:

	memmove(saved_data, data, len);
	... work over the data ...

---particularly if `working over the data' involves a linear pass over
all the items.  (TCP is a good example of this: it must copy outbound
data somewhere for retransmission, and it must also compute a checksum.
These operations can be done at the same time.)

Of course, when optimizing, the place to start is with a profiler.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov