From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!spool.mu.edu!samsung!usc!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!sei.cmu.edu!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.lang.ada
Subject: Re: Use pragma INLINE or not?
Message-ID: <27847@as0c.sei.cmu.edu>
Date: 27 Jun 91 16:13:50 GMT
References: <1991Jun18.171459.11744@software.org> <1991Jun19.234429.20796@netcom.COM>
Reply-To: firth@sei.cmu.edu (Robert Firth)
Organization: Software Engineering Institute, Pittsburgh, PA
List-Id: <comp.lang.ada>

In article <1991Jun19.234429.20796@netcom.COM> jls@netcom.COM (Jim Showalter) writes:

>Let the compiler inline when it can figure it out. Use a profiler
>to find bottlenecks when tuning the code, and manually inline the
>offenders. DON'T inline everything to "be sure"--this has a bunch
>of bad effects, and is completely unecessary (10% of your code uses
>90% of your CPU).

Ah, how true!  I remember writing my very first execution profiler,
for a machine that didn't have one.  To test it, I profiled a pretty
substantial program that I'd writen myself, maintained for a few
years, and with which I believed myself reasonably - nay, intimitely
- familiar.

Well, before profiling, I marked my guess at the top few time
sinks - obvious things such as the chain of 6 nested procedure
calls it took to emit one byte of output data.

All my guesses together accounted for 6% of the time. The number
one time sink was a search loop that I'd stupidly written the wrong
way round - the item being looked for was usually near the end of
the list rather than near the beginning.  Who would have believed
that mattered for a list of maximum length 18?  I reversed the
search and saved almost 20% of the time.