|
|
Log in / Subscribe / Register

Speed your code with the GNU profiler (developerWorks)

IBM developerWorks covers the use of the GNU profiler. "The performance needs of software vary, but it's probably not surprising that many applications have very stringent speed requirements. Video players are a good example: a video player is not much use if it can only play a video at 75 percent of the required speed. Other applications, such as video encoding, are lengthy operations that are best run "batch" style, where you start a job and leave it running while you go do something else. Although these types of applications don't have such hard performance limits, increasing speed will still bring benefits, such as being able to encode more videos over a given period and being able to encode at a higher quality in the same time."

to post comments

Speed your code with the GNU profiler (developerWorks)

Posted Apr 5, 2006 9:02 UTC (Wed) by wingo (guest, #26929) [Link] (2 responses)

Last time I tried it, in addition to having to recompile your app, the gnu profiler didn't understand shared libraries. It is worse than useless, because of the time you waste recompiling, only to get worthless results.

That said its analysis tools are good and well documented, which can't be said about most profilers.

Speed your code with the GNU profiler (developerWorks)

Posted Apr 5, 2006 9:28 UTC (Wed) by xorbe (guest, #3165) [Link]

As the fine article points out, you'll need to compile your libraries with -pg also, if I understood correctly.

Hmmm...

Posted Apr 5, 2006 13:31 UTC (Wed) by Los__D (guest, #15263) [Link]

I guess you didn't read the article.
And please don't blame the tool for your own shortcomings...

Speed your code with the GNU profiler (developerWorks)

Posted Apr 5, 2006 15:12 UTC (Wed) by busterb (subscriber, #560) [Link] (2 responses)

callgrind + kcachegrind is a profiler's dream (and it works with any
executable ;)

Speed your code with the GNU profiler (developerWorks)

Posted Apr 5, 2006 15:14 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

oprofile also rocks extremely... but gprof can do things like profile code running on remote systems and embedded boards, which oprofile has no hope of doing and valgrind is even further away from.

gprof remains the only *truly portable* free profiler.

Speed your code with the GNU profiler (developerWorks)

Posted Apr 5, 2006 17:38 UTC (Wed) by jzbiciak (guest, #5246) [Link]

Indeed. In fact, I just used gprof the other day on my Intellivision emulator while tuning it on a GP2X handheld that someone else owns.

There were still some downsides though. The GP2X version couldn't handle code compiled with optimization enabled, which is necessary to shoehorn my code into that little ARM CPU. Also, the _mcount_internal function that is part of gprof added 15-20% overhead of its own. So needless to say I wasn't quite realtime.

I still got a useful pie chart of where the time goes, though, so I know what the relative costs of functions are, even if I don't know the absolute costs.

Beware the limitations of gprof

Posted Apr 6, 2006 20:32 UTC (Thu) by jreiser (subscriber, #11027) [Link] (1 responses)

Be aware of the limitations of gprof. In particular, "info gprof" Inaccuracy, Assumptions:

Some of the figures in the call graph are estimates--for example, the `children' time values and all the time figures in caller and subroutine lines.

There is no direct information about these measurements in the profile data itself. Instead, `gprof' estimates them by making an assumption about your program that might or might not be true.

gprof has had this particular methodological failing since it was created 25 years ago. Fixing it requires a fundamental change: measuring the actual time that an arc in the call graph is active.

Beware the limitations of gprof

Posted Feb 26, 2010 19:56 UTC (Fri) by MikeDunlavey (guest, #63921) [Link]


Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds