Memory Profiling for Program C

I need to profile the memory of my C application.

It should include the size of the workspace and the size of RAM ...

for example if my application is similar 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 what memory should I consider for profiling footprint and RAM when loading a program.

is the following profiling correct? memory = 760 (where the flash or hard drive is installed) RAM = 67 + 8 + 0 = 75 bytes

Expert Suggestion

+5
source share
2 answers

Find object memory size

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 

Size outputs are the memory sizes of different parts of the object file:

  • text : (code segment) executable commands
  • data : (data segment) initialized global variables
  • bss : (block started by characters), statically assigned variables

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

The size you request is: ls output (which gives the size on disk) plus the dec part of the size command output, which gives you the size in RAM.

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

Find a memory area

When accessing the software application, footprint indicates the size of memory consumed by the running process (memory requirements at run time).

It is said that it is clear that when starting the process you must check the memory area. I think (and other posts confirm this) that the only real option is to use a tool like valgrind .

Your app profile with valgrind

You can profile memory with the Array tool. An array is heap profiling, but can also measure the size of the stack.

valgrind --tool = massif --stacks = yes

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

ms_print massif.out.

The first output in the file is a good diagram of memory usage during runtime.

 -------------------------------------------------------------------------------- Command: ./myprog -f d5.ini Massif arguments: --stacks=yes ms_print arguments: massif.out.24377 -------------------------------------------------------------------------------- MB 5.292^ ## | @ : : @@ : : # :::: : : | @:::: :: : :@:@@::::::::::::@ :::::::::::::# ::::@::::@:::::::: | @:: ::: :::::::::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@:::::::: | @:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@:::::::: | @:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@:::::::: | @:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@:::::::: | @:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@:::::::: | @:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@:::::::: | @:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@:::::::: | @@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@:::::::: | @@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@:::::::: | ::@@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@:::::::: | : @@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@:::::::: | : @@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@:::::::: | : @@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@:::::::: | : @@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@:::::::: | : @@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@:::::::: | : @@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@:::::::: | : @@:: ::: : :::: ::@:@ ::: :: :::: @ :: ::: ::::::# ::::@: ::@:::::::: 0 +----------------------------------------------------------------------->Gi 0 1.030 

Details are stored in a file, inside different tables. To fully understand the output, the Valgrind manual is referenced in a page that seems truly understandable.

Ability to track children: --trace-children=yes

Interestingly, there is no "actual memory usage in the process": https://unix.stackexchange.com/questions/164653/actual-memory-usage-of-a-process .

+4
source

This program is undefined: there is no main function.

The compiler reserves the right not to compile anything in this case, which leads to a zero size and memory size.

+2
source

Source: https://habr.com/ru/post/1235539/


All Articles