Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!psuvax1!rutgers!galaxy.rutgers.edu!argus!ken
From: ken@argus.UUCP (Kenneth Ng)
Newsgroups: comp.arch
Subject: Re: Compiler Costs
Message-ID: <1929@argus.UUCP>
Date: 13 Jul 90 23:06:06 GMT
References: <40052@mips.mips.COM> <628@dg.dg.com> <64045@sgi.sgi.com>
Organization: NJ Instit. of Tech: TEIES Project
Lines: 25

In article <64045@sgi.sgi.com>, karsh@trifolium.esd.sgi.com (Bruce Karsh) writes:
: In article <628@dg.dg.com> publius@dg-pag.webo.dg.com (Publius) writes:
: >Many "large" programs spend most of the CPU time in one or a few relatively
: >"tiny" routines.
: This is an often stated.  Is there any evidence for this?  What does the
: distribution of time look like for, for instance, a compiler?  I'd expect
:that there would be lots of time-sinks.  The lexical analyzer, the symbol table
: hash routine, the symbol table lookup routine, common subexpression finder,
: ... etc, could all be candidate time-sinks.

While there are undoubtably programs where most of the time is spent in a
few routines, I've been party to some 100K line programs where the profiler
indicated that the number one cpu user routine was using 2-3 % of the
resources, and the rest were in the low 0.5 to 2 % range, almost noise level.
And the top ten users were I/O routines, so I suspect the profiler was
catching them doing I/O to the various devices.  And yet I know of over
a dozen places where routines could be improved by doing a binary instead
of linear search.  (Whether or not there would be an improvement is 
debatable because then the entires would have to be inserted and moved
in order, and the average size was only a dozen or so.) 

-- 
Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey  07102
uucp !andromeda!galaxy!argus!ken *** NOT ken@bellcore.uucp ***
bitnet(prefered) ken@orion.bitnet  or ken@orion.njit.edu