Doh! Thanks, Nathan. I think you put your finger on it.
I was well aware of the overhead that gprof can introduce,
but did not recognize that this overhead was not being
counted by gprof.
Jon
Nathan Froyd wrote:
On Mon, Feb 22, 2010 at 03:23:52PM -0600, Jon Turner wrote:
In it, you will find
Ok, this is not as simple as I would like to make it,
but hopefully it's simple enough. I've placed a tar file at
www.arl.wustl.edu/~jst/gprof-tarfile
In it, you will find a directory with all the source code
needed to observe the problem for yourself.
The top level directory contains a linux ex
it. But at the moment,
it's hard to avoid the suspicion that something about the
gprof implementation is deeply flawed.
Jon
Joern Rennecke wrote:
Quoting Michael Matz :
Hi,
On Sun, 21 Feb 2010, Jon Turner wrote:
I have recently encountered a gross inaccuracy in gprof that
I can't
Yes, it is statically linked. In any case, there is very
little usage of external libraries here.
Jon
Alan Modra wrote:
On Sun, Feb 21, 2010 at 12:27:04PM -0600, Jon Turner wrote:
The program in question has been compiled with -pg for all
source code files.
Linked statically too? If not
rong with either gprof or the way
I am using it.
Jon
-Original Message- From: gcc-ow...@gcc.gnu.org
[mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Jon Turner Sent: Sunday,
February 21, 2010 7:27 PM To: gcc@gcc.gnu.org Subject: Gprof can
account for less than 1/3 of execution ti
I have recently encountered a gross inaccuracy in gprof that
I can't explain. Yes, I know gprof uses a sampling technique
so I should not expect a high level of precision, but the results
I am getting clearly reflect a more fundamental issue.
The program in question has been compiled with -pg for
