Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!stanford.edu!leland.Stanford.EDU!elaine18.Stanford.EDU!dhinds
From: dhinds@elaine18.Stanford.EDU (David Hinds)
Newsgroups: comp.sys.sgi
Subject: Re: profiling woes, prof has changed???
Message-ID: <1991May25.230517.9808@leland.Stanford.EDU>
Date: 25 May 91 23:05:17 GMT
References: <1991May25.220250.11321@cs.yale.edu>
Sender: news@leland.Stanford.EDU (Mr News)
Distribution: usa
Organization: Stanford University - AIR
Lines: 28

In article <1991May25.220250.11321@cs.yale.edu> dan@omega.chem.yale.edu (Dan Severance) writes:
>
>   Hi,
>     I've been using pixie to profile my files for a long time now.
>I recently tried it, and when time came to use prof -pixie file,
>I get:  (twnew is the mainline, wpot is the only subroutine)
>   prof -pixie bestc 
>
>wpot_ is an alternate entry within twnew_ (bestc.f) 
>
     I haven't done this with Fortran, but I presume this means that the
subroutine has been inlined and no longer exists as a separate entity.
Because other optimizations may obscure the boundary between the original
code in the main program and the subroutine, it may not be possible to
separate out the time spent in an inlined routine.  In any case, I guess
pixie can't look at the executable and figure out that wpot was once a
separate routine.  I've gotten used to seeing funny things in profiles
of fully optimized code, like single lines of source that generate 600
bytes of code as a result of inlining.  How to avoid this?  Put another
call to this subroutine somewhere else in your program, where it won't
ever be executed (but not so the compiler can figure that out).  Or even
put a recursive call in (also so it will never execute).  These should
force the compiler to not inline the routine.  You'll get a slightly non-
optimal profile, but it should be OK if all you are interested in is the
time spent in the routine itself.

 -David Hinds
  dhinds@cb-iris.stanford.edu