Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!snorkelwacker!paperboy!husc6!m2c!umvlsi!dime!yodaiken
From: yodaiken@chelm.cs.umass.edu (victor yodaiken)
Newsgroups: comp.arch
Subject: Re: Compiler Costs
Message-ID: <16883@dime.cs.umass.edu>
Date: 14 Jul 90 00:15:58 GMT
References: <40052@mips.mips.COM> <628@dg.dg.com> <64045@sgi.sgi.com> <1990Jul13.173331.22918@zoo.toronto.edu>
Sender: news@dime.cs.umass.edu
Reply-To: yodaiken@chelm.cs.umass.edu (victor yodaiken)
Organization: University of Massachusetts, Amherst
Lines: 20

In article <1990Jul13.173331.22918@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>
>My personal feeling is that the "hot spot" principle has become accepted
>dogma on the basis of rather few actual cases, the most infamous being
>the XPL compiler that spent all of its time skipping trailing blanks in
>card images.  I suspect that a lot of hot-spot examples are the result
>of something like this:  stupid code, or a stupid data format.
>
>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.
>-- 

That was my experience in trying to speed up an o.s. Major speed losses
seemed to be the result of propagation of minor speed losses.  Rather than
hot spots, we found long execution paths and repeated recomputation of
data that could be cached.