[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Makefile and gprof problem

From: RS
Subject: Re: Makefile and gprof problem
Date: Fri, 29 Dec 2006 10:58:51 -0500
User-agent: Thunderbird (Macintosh/20060909)

Paul Pluzhnikov wrote:
RS <> writes:

In the abbreviated version of the code, the output of "time ./program" is

real    0m57.768s
user    0m40.878s
sys     0m7.812s

This says: most of the time is spent in user-level code.
Such code consists of:
1. your own code (main exe, libraries, etc.), and
2. "system" libraries (libc.dylib (or whatever it's called on OSX))

Hi Paul and thanks again for your reply,

OK Thanks, so most of the time is in the user level, which it makes
sense because my code has many calls to 2D convolutions, linear algebra,
and other user defined code that one would expect take some time to run.

For the same abbreviated code, gprof claims that both the total time
and self time of all the functions (including main) are 0.0.

Gprof can only measure code that was compiled with '-pg' (1 above),
but not code compiled without it (2 above).

My user defined code was compiled with -pg (and linked with -pg also).
But I guess what you are saying below is, as long as system files are
not compiled with -pg, then gprof does not help me profile my own code
because compilers automatically can link do system libraries.

Sorry for my confusion. It is lack of sleep:-) But I don't see how then
one can in general use gprof, because most of the time one doesn't have
access to system libraries that were built  with -pg. I mean, one can
not recompile libc.a every time one wants to use a profiler

guess I don't understand the fundamental thing about gprof, because I
thought I could get some idea of how much time is spent in each

It can.
The problem is that (apparently) 99.99% of time is spent *not*
in your functions, but in "system" code. In order for gprof
to tell you which *your* functions contribute to the execution time
(by calling some "slow" system functions), you must link with
'-pg'-compiled versions of system libraries (as I've already
told you).

Well, I  know for fact that my user defined code takes some time to run
(extensive use of loops and user defined convoluted functions). But even
if 99.99% of the time is spent in system libraries, one would still
expect that the total time (or even self time) of the main function
would show something other 0.0. Anyway, I guess one of my questions was
weather I had used the correct syntax in my makefile (posted in my
original question) and I guess the implicit answer is yes I did. So I'll
go back scratching my head...

The (static) library, libfoo.a, that I link with, is my own defined
library, which I have put all the functions in. It is not a system

And it (apparently) doesn't contribute much to total execution time.
Note that even if you don't see "system" libraries on your link line,
that doesn't mean none are used: compiler adds such libraries

Are you saying that gprof can not go into the libraries?

No. I am saying that gprof can not go into non-'-pg'-compiled
libraries, and (on some platforms) not into dynamic libraries.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]