Profiler Problems

I'm using gprof to profile my program. I run the program and produce the file gmon.out, which I interpret with gprof. The result is a text file with my profile data in. However, while there is data in this file pertaining to the number of function calls, function names, etc, all of the time data is zero. Can anyone suggest why this is indeed the case?

The timers have a granularity, which is greater than what it takes to execute very short functions.

Isn't that in the gprof FAQ?

There's the online documentation, although I can't find any relevant information in that. Perhaps I'm looking in the wrong places, or perhaps it's not there...

Odd, this sticks out like a sore thumb.
http://www.gnu.org/software/binutils...rof.html#SEC19

Yes, I looked there, but what I'm saying is that I can't find the information I need in that documentation...

I just found this in my file, which corroborates your idea:

granularity: each sample hit covers 4 byte(s) no time accumulated

I searched for granularity in the documentation, but I didn't find any info regarding how to change it. Any ideas?

I think I may have found the reason for the empty data file... It seems that most of the runtime is due to system overhead, although I don't know why this is so. I don't write/read from files much or issue any explicit system() commands. Could it be due to overtaxing the RAM?

I'm getting bored of reading the manual for you

Originally Posted by gprof

This is done is one of two ways. Most UNIX-like operating systems provide a profil() system call, which registers a memory array with the kernel, along with a scale factor that determines how the program's address space maps into the array. Typical scaling values cause every 2 to 8 bytes of address space to map into a single array slot. On every tick of the system clock (assuming the profiled program is running), the value of the program counter is examined and the corresponding slot in the memory array is incremented. Since this is done in the kernel, which had to interrupt the process anyway to handle the clock interrupt, very little additional system overhead is required.

So the first answer is "not without serious kernel or gprof hacking".

As for your other question, I've no idea what "overtaxed RAM" is, unless your "ISR" has been replaced by an "IRS".

Maybe post some code if you want a better explained answer.

Thanks for the info, Salem. The code is several thousand lines and I have no idea where in the code the problem is (as that's what I was using the profiler for), so I can't post any code, unfortunately. Back to the drawing board...