[ale] gcc

Charles Shapiro cshapiro at nubridges.com
Wed Apr 3 09:18:14 EST 2002


Right On Dude. Code is for people to read. Leave optimization to the
machine.  Use a profiler to determine speed bottlenecks; the results
will often surprise you.  
A coding buddy of mine once tried to speed up a billing program which
took almost a full day to run on a large machine. He neglected the
profiling step ('cause he thought he already knew the answers) and spent
over a week making every sequential search in the thing into a binary
search.  Total time saved: about 10 minutes in a 22-hour run.
Micro-optimization is nearly always a waste of time compared to
redesigning your algorithm for more speed.

-- CHS

-----Original Message-----
From: Danny Cox [mailto:danscox at mindspring.com]
To: ale at ale.org
Sent: Wednesday, April 03, 2002 7:02 AM
To: ALE Mailing List
Subject: Re: [ale] gcc
<<snip>>

	Okay, hold it right there, buckaroo!  While all these ideas are
good,
most programmers get caught in the trap of early optimization, usually
at the expense of readability.  In your example above:

	for t=1 to 10 do
	    if x < 3*t then
		do_stuff;

in my opinion should remain as it is.  Why?  Because that's probably NOT
the bottleneck in the program!  Code for readability first (if you've
got to maintain it, you'll save yourself grief later, and if it's
someone else, they'll thank you), then use a profiler to see where the
code is using most of it's time *if you need to*!  If it's fast enough
already, leave well enough alone!

---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be
sent to listmaster at ale dot org.






More information about the Ale mailing list