Clock_gettime showing high usage during profiling of code

Question

I am profiling a userland application on netbsd with gprof and seeing clock_gettime using upwards of 30% cycles. Gprof does not show where it is getting called from (it shows some function which clearly does not call clock_getttime). The application uses third party code including libevent 1.4 (which appears to use clock_gettime). I looked into removing the call from that but could not determine much.

1. I don't understand why it would take that much of time. Any inputs will be appreciated. I also saw gettimeofday taking a lot of cycles. In general, why would getting the time involve so many processing cycles
2. Is there a way that one can optimize clock_gettime () or can we use any other call?
3. Is it possible that gcc itself adds this call to the code when it is compiled with -pg for profiling purposes? Thanks for any answers

Answer 1

It's all relative to whatever else your program is doing, and keep in mind that if you're doing any I/O, the actual CPU time your program uses may be small, and gprof doesn't see anything else. So if some calls to timing routines get stuck in there, and they are called often enough, sure they can show a high percent.

Why doesn't gprof show where they're being called from? For routines compiled with -pg, it tries to figure out who the caller is when any routine is entered. It tries, but that doesn't mean it succeeds. Anyway, that's gprof.