1

I'm trying to use gprof for profiling an opengl app. Since main draw function gets called dozens times in a second, the times spent in particulas functions are small. gprof output contains times formatted as "%.2f" and almost all times are equal 0.00:

[4]     35.2    0.00    0.06    9414         AbstractLayer::render(IDrawContext&) [4]
                0.00    0.02    1046/1046        SimpleTiledImageLayer::doRender(IDrawContext&) [9]
                0.00    0.02    1046/1046        AtmosphereLayer::doRender(IDrawContext&) [10]
                0.00    0.01    1046/1046        GeographicObjectLayer::doRender(IDrawContext&) [23]
                0.00    0.01    1046/1046        POILayer::doRender(IDrawContext&) [27]

Is there any possibility to make it print time more precisely?

Equidamoid
  • 1,447
  • 1
  • 13
  • 24
  • 1
    If you're profiling because you want to find "bottlenecks" so you can speed things up, what matters is low precision inclusive percent. [*Check here.*](http://stackoverflow.com/a/1779343/23771) Not high precision, not seconds or milliseconds, not "self" time, not how many calls. The reason is, if there is a "bottleneck" you can fix, it is in *your* code and is costing a significant fraction of overall time. Things that cost small fractions will only save small fractions if you speed them up. – Mike Dunlavey Sep 16 '12 at 16:04
  • 1
    ... (continued) If you think the only things you can speed up are small things - that your program is already close to optimal - *maybe* you're right, and maybe there is a big speedup opportunity in there that you're not seeing because the profiler doesn't show it to you. That's a [*false negative*](http://scicomp.stackexchange.com/a/2719/1262). False negatives can be big sleepers. – Mike Dunlavey Sep 16 '12 at 16:14

1 Answers1

0

I've just modified the source and recompiled binutils. That was simple =)

Equidamoid
  • 1,447
  • 1
  • 13
  • 24