1

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
doon
  • 2,311
  • 7
  • 31
  • 52

1 Answers1

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.

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
  • Thanks. Are there any way to optimize clock_gettime or compare performance of different timers that clock_gettime can potentially use – doon Jul 23 '13 at 06:41
  • @doon: See, I don't optimize that way. I look for what in my own code is responsible for time being spent. [*I use this method.*](http://stackoverflow.com/a/378024/23771) – Mike Dunlavey Jul 23 '13 at 11:49