Re: Makefile and gprof problem

[Paul Pluzhnikov]

RS <rsina_no.ssppaamm@comcast.net> 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))

> 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).

> 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
> function

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).

> 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
> library.

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
automatically.

> 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.

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.