Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rutgers!bellcore!messy!mo
From: mo@messy.bellcore.com (Michael O'Dell)
Newsgroups: comp.arch
Subject: Re: Compiler Costs
Message-ID: <25338@bellcore.bellcore.com>
Date: 13 Jul 90 21:26:10 GMT
References: <40052@mips.mips.COM> <628@dg.dg.com> <64045@sgi.sgi.com> <1990Jul13.173331.22918@zoo.toronto.edu>
Sender: news@bellcore.bellcore.com
Reply-To: mo@bellcore.com (Michael O'Dell)
Organization: Center for Chaotic Repeatabilty
Lines: 23

In article <1990Jul13.173331.22918@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>
>Our experience with C News was that there never was a single massive hot
>spot.  Typically the profile would show half a dozen major contributors
>to execution time and then a long tail of smaller ones.  Often, the
>way to fix it was *not* to optimize the profile leaders, but to look at
>where they were being called from and why, and streamline the algorithms
>in the callers.



Ohh Yes!! The ol' maxim of 

	There's no substitute for knowin' what the *&$# you're doin'!!!!

I must agree with Henry - after the the trivially-obvious things are eliminated
you have to actually optimize the work, not the code.

	-Mike

---------------

"The obvious is immediately apparent if you look closely enough."