Path: utzoo!attcan!uunet!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!aglew
From: aglew@oberon.crhc.uiuc.edu (Andy Glew)
Newsgroups: comp.arch
Subject: Re: Compiler Costs
Message-ID: <AGLEW.90Jul13090626@oberon.crhc.uiuc.edu>
Date: 13 Jul 90 13:06:26 GMT
References: <40052@mips.mips.COM> <628@dg.dg.com> <64045@sgi.sgi.com>
Sender: usenet@ux1.cso.uiuc.edu (News)
Organization: University of Illinois, Computer Systems Group
Lines: 40
In-Reply-To: karsh@trifolium.esd.sgi.com's message of 13 Jul 90 06:15:36 GMT

>When I've profiled programs, I've often found that the time is spent mostly
>in a few routines, but this isn't always the case.  How often is it true that
>nearly all of the time is spent in only a few routines?  How often are these
>routines tiny?
>
>			Bruce Karsh
>			karsh@sgi.com

I, also, have profiled programs where the 90%/10% for routines rule
doesn't apply.  Well, actually, in a few that I have investigated in
detail there was some sort of ratio rule applicable to *types* of
code, but not according to routine. For example, I have seen programs
where 50% of the time was spent in function calling and returning,
manipulating variables, etc. The problems were (1) determining what
types of classifications (time spent function calling, time spent in
loop overhead, time accessing method variables...) were appropriate,
and (2) getting my profiler to tell me how much time was spent
according to each classification.
    Unfortunately, most profilers do not have a way of indicating "X%
of your time was spent in function calling". Gprof tends to provide
function granularity (possibly with programmer provided parts).
That's why I quickly fall back to "flat" profiling, done at the
instruction level, for then I can classify instructions according to
"purpose".  I wish I had access to a commercial profiler that does
this. Is there one?
    Finishing the anecdote... the program that spent 50% of its time
in function calls? --- It was one of those well-structured "CS"
programs :-) [*] that had lots of small functions called all over the
program.  Inlining (actually, back then I macrofied - didn't have
access to a compiler with inlining) functions with fewer than 10 lines
of code in their bodies got me most of the necessary improvement.


[*] This is just a mild reference to Karsh et al's parallel discussion.
    I don't want to get involved in that dispute.  I *like* well-structured
    programs with lots of subroutines.  I just wish that all of my compilers
    did inlining automatically.

--
Andy Glew, aglew@uiuc.edu