Array indexing vs. pointers...

[Walter Bright]

In article <8630 at smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>I have to take exception to most of these micro-efficiency tweaks.

For brevity, I've taken the liberty of paraphrasing your objections:
>1. Optimizing the algorithm is more important than the low level code.
>2. Low level tweaks are not portable.
>3. Low level tweaks are less clear.
>4. A good compiler should do this optimization for you.
>5. On machine X with compiler Y this optimization will make things worse.

All true. However,
1. After you've optimized the algorithm, then you go after the low level
   code. My article was about opportunities for tweaking low level code.
2. Frankly, I don't care about portability to the following machines:
	o 1's complement
	o NULL pointers aren't 0 bit patterns
	o 0 double values aren't 0 bit patterns
   I've never met one, and I'll worry about them if and when I have
   the misfortune of dealing with them. I worry about Vaxes, 68ks,
   8086, 286, 386, and 32032.
3. A matter of opinion. I've met programmers who would go to extreme
   lengths to avoid using the ^ & | operators because they thought that
   bit operations were 'obscure'.
4. Most of us have to use compilers whose optimizations are less than
   perfect. In fact, there are hardly any global flow analysis compilers
   out there.
5. In writing code for machines A, B and C, I write to the lowest common
   denominator, and hand-tweak for the slowest machine.

Micro-efficiency gets regularly denounced. Here are some counterarguments:
o	If your commercial product is slower than the competition, you
	won't get a chance to take advantage of the maintainability/
	portability advantages because you'll be out of business.
o	The sum of all the tweaks can make the difference (on the PC)
	between using a small memory model and the large. This gives
	a lot of leverage to seemingly minor changes.
o	I derive a lot of personal satisfaction from creating 'lean
	and mean' code.
o	Run-time speed makes the difference between a user interface
	that's crisp and snappy and one that's sloppy and sluggish.
o	Customers want speed. I've been selling consumer software for years,
	and I know. Speed *sells*. Telling the customer to buy faster
	hardware doesn't work.
o	Streamlining code even in relatively unused sections of code is
	important, because it reduces the size of the executable. Smaller
	programs run faster because:
	.	Less virtual memory paging
	.	Might be able to use smaller memory model
	.	Fewer overlays are necessary
	.	More memory is available, so you can trade execution speed
		for more memory consumption in your data structures
	.	They compile faster
	.	They link faster
	.	They load faster