memory profiling for C program

Question

Need to do a memory profiling of my C application ..

It should include footprint size and a RAM size ...

for example if my application is like below ..

#include <stdio.h>

int global = 10; /* initialized global variable */

int test_code(void)
{
    static int i = 100; /* Initialized static variable*/
    return 0;
}

Output:

[putta@linux]$ gcc memory-layout.c -c memory-layout 

[putta@linux]$ ls -ltrh  memory-layout.o
760 Nov  9 18:26 memory-layout

[putta@linux]$ size memory-layout.o
   text    data     bss     dec     hex filename
     67       8       0      75      4b memory-layout.o

So now which memory I should be considered for profiling footprint, and RAM when the program is loaded ..

is the below profiling is correct? footprint memory = 760 (which is sits flash or harddisk) RAM = 67+8+0 = 75 Bytes

Need suggestion from experts

Answer 1

Find the memory size of the object

If you want to know the size of your program on disk plus the size of text and data in RAM, on Linux/Unix you can use the size command:

$> size /bin/cat
text       data     bss     dec     hex filename
43422      1720    2472   47614    b9fe /bin/cat

The outputs of size are the memory sizes of different parts of the object file:

• text: (code segment) executable instructions
• data: (data segment) initialised global variables
• bss: (block started by symbols) statically-allocated variables

The last two columns, dec and hex, are respectively the sum of the other three (the overall size) in decimal and hexadecimal.

The size you are asking for is: the output of ls (that gives you the size on disk) plus the dec part of the output of the size command that gives you the size on RAM.

See also these posts: http://www.cyberciti.biz/faq/linux-find-size-of-text-data-segment-bss-uninitialized-data/, how to know the memory footprint of my binary executable

Find the memory footprint

When referring to a software application the footprint indicates the size of the memory consumed by the running process (runtime memory requirements).

Said that, it is clear that you should check the memory footprint when the process is running. I think (and other posts confirm it) that the only real option is to use a tool like valgrind.

Profile your application with valgrind

You can profile the memory using the Massif tool. Massif is an heap profiler but can also measure the size of the stack.

valgrind --tool=massif --stacks=yes

This will give you both the heap and stack memory usage. Then the information are stored in the file massif.out.???? that you can read with

ms_print massif.out.?????

The first output in the file is a nice chart of the memory usage during the running time.

--------------------------------------------------------------------------------
Command:            ./myprog -f d5.ini
Massif arguments:   --stacks=yes
ms_print arguments: massif.out.24377
--------------------------------------------------------------------------------


    MB
5.292^                                                    ##                  
     |    @                 :           :  @@   :      :  # ::::   :  :       
     |    @:::: ::    :   :@:@@::::::::::::@ :::::::::::::# ::::@::::@::::::::
     |    @:: ::: :::::::::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@::::::::
     |    @:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@::::::::
     |    @:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@::::::::
     |    @:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@::::::::
     |    @:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@::::::::
     |    @:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@::::::::
     |    @:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@::::::::
     |   @@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@::::::::
     |   @@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@::::::::
     | ::@@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@::::::::
     | : @@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@::::::::
     | : @@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@::::::::
     | : @@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@::::::::
     | : @@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@::::::::
     | : @@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@::::::::
     | : @@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@::::::::
     | : @@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@::::::::
   0 +----------------------------------------------------------------------->Gi
     0                                                                   1.030

The details are stored in the file, inside different tables. To fully understand the output refers to the Valgrind manual page which seems really clear.

The option to trace the children is: --trace-children=yes

Interesting, it seems that there is no "actual memory usage of a process": https://unix.stackexchange.com/questions/164653/actual-memory-usage-of-a-process.