Valgrind Tutorial Part 6 -- Callgrind

As we already valgrind is basically a wrapper around a lot of tools.In the previous posts, we were using the most popular valgrind tool known as memcheck,today we will be using another tool known as callgrind.


Before knowing about callgrind we have to know about profiling in programming...

What is profiling?

Profiling is a form of dynamic program analysis,that measures things such as
 1.Time complexity
 2. Space complexity
 3. How many times a particular function is called.
 4. Time taken to execute a particular function.

Basically , we use it to find where our program is taking more amount of time and try to optimize it.

So there are many tools which performs profiling operation such as gprof..valgrind also has a tool i.e.,callgrind..So, we now know that cachegrind is  a profiling tool.

So,in order to use this tool,you have to specify --tool=cachegrind as an argument to the valgrind else the default tool memcheck will be considered.


So, in order to perform profiling on your application, first compile the application with debugging information enabled(-g flag passed to gcc)

Then run the valgrind command

valgrind --tool=callgrind <exe>

O/P:

==4747== Callgrind, a call-graph generating cache profiler
==4747== Copyright (C) 2002-2011, and GNU GPL'd, by Josef Weidendorfer et al.
==4747== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==4747== Command: test
==4747== 
==4747== For interactive control, run 'callgrind_control -h'.
==4747== 
==4747== Events    : Ir
==4747== Collected : 241683
==4747== 
==4747== I   refs:      241,683


You can see when you run the above command you get a o/p saying that  it has collect 241683 events, and will create a file callgrind.out.4747 which has all the events.The  4747 which is present in the file name is actually the pid of the application.You can use any editor to open the file,but if you want more descriptive information in an understandable manner,you have to run the following command in terminal.

callgrind_annotate --auto=yes callgrind.out.4747

--------------------------------------------------------------------------------
Profile data file 'callgrind.out.4747' (creator: callgrind-3.7.0)
--------------------------------------------------------------------------------
I1 cache: 
D1 cache: 
LL cache: 
Timerange: Basic block 0 - 51658
Trigger: Program termination
Profiled target:  test (PID 4747, part 1)
Events recorded:  Ir
Events shown:     Ir
Event sort order: Ir
Thresholds:       99
Include dirs:     
User annotated:   
Auto-annotation:  on

--------------------------------------------------------------------------------
     Ir 
--------------------------------------------------------------------------------
241,683  PROGRAM TOTALS

--------------------------------------------------------------------------------
    Ir  file:function
--------------------------------------------------------------------------------
67,632  /build/buildd/eglibc-2.15/elf/dl-addr.c:_dl_addr [/lib/i386-linux-gnu/libc-2.15.so]
26,007  /build/buildd/eglibc-2.15/elf/dl-lookup.c:do_lookup_x [/lib/i386-linux-gnu/ld-2.15.so]
22,548  /build/buildd/eglibc-2.15/elf/dl-lookup.c:_dl_lookup_symbol_x [/lib/i386-linux-gnu/ld-2.15.so]
13,511  /build/buildd/eglibc-2.15/elf/../sysdeps/i386/dl-machine.h:_dl_relocate_object
13,033  /build/buildd/eglibc-2.15/string/../sysdeps/i386/i686/multiarch/../strcmp.S:strcmp [/lib/i386-linux-gnu/ld-2.15.so]
.....
You can see in the output something like Ir,it is nothing but Instruction read events,you can also see it displays each function and its Ir count  and the file in which it is present

What are Ir counts?

         Each C program has so many lines of code, each line of code can be converted into one,two or more than two assembly instructions depending on the operation.Ir counts specifies the number of assembly instructions executed.






Comments

Popular posts from this blog

bb.utils.contains yocto

Difference between RDEPENDS and DEPENDS in Yocto

PR, PN and PV Variable in Yocto