A collection of code profiling techniques follows.
Typical problems with dynamic memory management are:
While the latter is rather tricky to analyse, for memleaks there is
valgrind. Invocation as follows:
$ gcc -g test.c $ valgrind --leak-check=full ./a.out
When programming, code complexity (O-notation) is the main factor identifying CPU-intense algorithms. Reducing code complexity often doesn't suffice, though. E.g. IO-intense operations often lead to delays at run-time which isn't covered by O-notation, at all. This means that aside of complexity analysis, there always should be run-time code execution time measurement.
gprof is a profiler integrated into gcc. Enabled at compile-time, the
program collects profiling data for later analysis using
$ gcc -pg -g test.c $ ./a.out $ gprof a.out gmon.out
On recent kernels,
perf is the best tool for the job. It may profile the
whole system like with obsoleted OProfile but may be limited to a single
program, also. Before executing the workload to profile (or while it is
# perf record
When done, finish recording using
CTRL-c. perf data will be written to perf.data in local directory. To analyse, call:
# perf report
Profiling Python is pretty simple, using cPython module:
$ python -m cPython myscript.py
Code coverage means to have a look at how often each line of code is being
executed. Interestingly, this can be used to “measure” the code's complexity.
This way a broader view over the problem can be provided, e.g. answering the
question if a seldomly executed O(n) algorithm is heavier than an O(log(n))
one being executed all the time. One of the best tools to analyse the code
$ gcc -fprofile-arcs -ftest-coverage test.c $ ./a.out $ gcov tmp.c
this will create the file test.c.gcov containing the annotated source code of test.c.
If linking happens in a separate step, some additional flags have to be passed to linker:
CFLAGS += -fprofile-arcs -ftest-coverage LDFLAGS += -lgcov --coverage