|Valgrind 3.3 - Advanced Debugging and Profiling for GNU/Linux applications|
by J. Seward, N. Nethercote, J. Weidendorfer and the Valgrind Development Team
Paperback (6"x9"), 164 pages
RRP £12.95 ($19.95)
7.3.1 Multiple profiling dumps from one program run
Sometimes you are not interested in characteristics of a full program run, but only of a small part of it, for example execution of one algorithm. If there are multiple algorithms, or one algorithm running with different input data, it may even be useful to get different profile information for different parts of a single program run.
Profile data files have names of the form
where pid is the PID of the running
program, part is a number incremented on each
dump (‘.part’ is skipped for the dump at program termination), and
threadID is a thread identification
(‘-threadID’ is only used if you request dumps of individual
There are different ways to generate multiple profile dumps while a program is running under Callgrind's supervision. Nevertheless, all methods trigger the same action, which is “dump all profile information since the last dump or program start, and zero cost counters afterwards”. To allow for zeroing cost counters without dumping, there is a second action “zero all cost counters now”. The different methods are:
Dump on program termination.This method is the standard way and doesn't need any special action on your part.
Spontaneous, interactive dumping.Use
callgrind_control -d [hint [PID/Name]]to request the dumping of profile information of the supervised application with PID or Name. hint is an arbitrary string you can optionally specify to later be able to distinguish profile dumps. The control program will not terminate before the dump is completely written. Note that the application must be actively running for detection of the dump command. So, for a GUI application, resize the window, or for a server, send a request. If you are using KCachegrind for browsing of profile information, you can use the toolbar button
Force dump. This will request a dump and trigger a reload after the dump is written.
Periodic dumping after execution of a specified number of basic blocks. For this, use the command line option
Dumping at enter/leave of specified functions.Use the option
--dump-after=func. To zero cost counters before entering a function, use
--zero-before=func. You can specify these options multiple times for different functions. Function specifications support wildcards: e.g. use
--dump-before='foo*'to generate dumps before entering any function starting with foo.
Program controlled dumping.Put
#include <valgrind/callgrind.h>into your source and add ‘CALLGRIND_DUMP_STATS;’ when you want a dump to happen. Use ‘CALLGRIND_ZERO_STATS;’ to only zero cost centers. In Valgrind terminology, this method is called “Client requests”. The given macros generate a special instruction pattern with no effect at all (i.e. a NOP). When run under Valgrind, the CPU simulation engine detects the special instruction pattern and triggers special actions like the ones described above.
If you are running a multi-threaded application and specify the
command line option
every thread will be profiled on its own and will create its own
profile dump. Thus, the last two methods will only generate one dump
of the currently running thread. With the other methods, you will get
multiple dumps (one for each thread) on a dump request.
|ISBN 0954612051||Valgrind 3.3 - Advanced Debugging and Profiling for GNU/Linux applications||See the print edition|