“Sometimes System Administrators need to determine where applications spend most of their time, in order to tune their systems better. The traditional method, when the source code for the application and gcc are available, is just to recompile the application with the – pg flag and to use gprof to profile it. Other than the inconvenience of the recompilation process, the solution is pretty straightforward. But what happens when you don’t have the source code for the application? And what if you’d like to profile the system as a whole? That’s when oprofile comes in handy.“
Low-Overhead Statistical Profiling with Oprofile
About The Author
Adam Scheinberg
Technology Executive • Web Developer • Father • Foodie • Music Snob • OS enthusiast
Follow me on Mastodon @[email protected]
What’s the use of profiling if you cannot change anything in the code anyway? And what’s the use of profiling which shows you its results at the granularity of libraries (not functions)?
Funny, I thought that Oprofile was years ahead of the “useless” Dprobe tech built into solaris 10?
OProfile is a crude performance shovel compared to DTrace. Not only is OProfile too kernel specific in it’s options, but it has poor support for custom aggregation of data, and no support that I can see for custom application probes. DTrace wins again.
What’s the use of profiling if you cannot change anything in the code anyway?
You can change anything that you have source for. If you don’t have source for a particular component (e.g. a shared library used by your application), you can perhaps alter your usage pattern for that component to increase overall performance.
And what’s the use of profiling which shows you its results at the granularity of libraries (not functions)?
OProfile can give function-level (or even instruction-level) output, as shown in the article.
As for DTrace, it is not a profiler. You can use DTrace for profiling, but since it isn’t designed as a profiler you shouldn’t be surprised that the results are not as good as a dedicated profiler like OProfile. Likewise, OProfile simply does not do many things that DTrace does, because it is just designed to do profiling.
Finally, I would like to complain that terminal screen shots are really wasteful when some PRE tags would have worked just as well.
I am working on a new Kick ass profiler. And it’s visual and all, Screenshots are available:
http://vprofiler.sf.net/
Nadav256 AT Gmail Dot Com
Another alternative to oprofile is Sysprof, a profiler that uses a Linux kernel module to profile the entire system, rather than just a single application.
It handles shared libraries, and applications do not need to be recompiled. It has a nice graphical interface that shows the time spent in each branch of the call tree, and it can load and save profiles.
It is really easy to install and use.
Find it here:
http://www.daimi.au.dk/~sandmann/sysprof/
What exactly defines a profiler? I sat through a 2 hour techinical presentation on DTrace by a Sun Kernel dev. Although it ‘simply’ traces instructions, I don’t see how it cannot be used as a powerful profiler as well…
i.e. It seems like it can do everything VTune can do (and more), and VTune is a “Real” Profiler right?
“As for DTrace, it is not a profiler. You can use DTrace for profiling, but since it isn’t designed as a profiler you shouldn’t be surprised that the results are not as good as a dedicated profiler like OProfile. Likewise, OProfile simply does not do many things that DTrace does, because it is just designed to do profiling.”
Can you give any example what can be achived with OProfile and not with DTrace? Actually it looks like DTrace is better for profiling than OP ‘coz DTrace can for example measure exact numbers (time spent in functions, etc.) and not only some coarse aggregation in a time interval (although it can do it that way too).