This chapter covers several methods to measure execution time and real-time performance. The methods give different types of granularity, from the program’s complete execution time to how long each function in the program takes.
Profiling in Linux Performance Tuning
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Is this supposed to be a new book? If yes, then the sample chapter is not that convincing. First half wasn’t bad (stopwatch really is a good and useful way of benchmarking), but gprof? Come on, gprof is so 90’s. It’s useless these days, it doesn’t even work with shared libraries. Where’s cachegrind or sysprof?
I beg to differ. I (still!) consider gprof to be an extremely useful tool. Not in the least because of it’s surprising ease of use: if you thought profiling is hard, think again.
I agree for $45 you’d expect a book to go further than this, but imho not covering gprof would have been a mistake. On the other hand, it seems to have good step-by-step instructions, so I’m sure there’s a market for this actually.
I suggest you actually try cachegrind or sysprof. If you consider recompiling everything and analyzing a large tree written in a text file to be ease of use, I wonder what you’ll call these two when all you have to do is to run them and then have a better view of the data in GUI. It still won’t do the thinking for you though
. Profiling is not hard, thinking about the results is.
The main issue is gprof’s inability to deal with shared libraries; and who knows does it even deal with threads?
I used to use gprof, but I’ve had no use for it lately. It’s nice for some things, say I have test cases for classes then I’d use gprof cause it has nice readable output and it’s not a big user requirement.
I completely agree with Zelv on sysprof. Look at the magical coding ninja monkey Federico’s performance analysis of gnome using tools like sysprof, exmap, etc.
http://primates.ximian.com/~federico/news.html