C memory profiler

[samit700]

Hi,
I am looking for an advanced memory profiler for C programs. I need to study the memory model including alloc,dealloc,realloc,accesses,etc. of certain benchmark programs, find bottlenecks and patterns which causing delay at various points in the code due to thrashing, too many disk accesses, etc. I would also like to see the OS page-in/page-out trace during program execution. The purpose of this analysis will be to optimize program execution for different instances and architectures. The optimization will primarily be focussed on optimizing memory access and allocation for different cases and making program more adaptable.

Does anyone know of any such comprehensive memory profiler.

Appreciated.

Samit

 

[Salem]

> I would also like to see the OS page-in/page-out trace during program execution.
1. For which operating system?
2. You do realise that the OS decision to swap out one of your pages is heavily dependent on the load presented by all the other processes the OS is looking after.

First port of call is to use a tool like 'gprof' to work out the execution call graph for the program in question.
Because until you've optimised the code, messing about with reordering data to make it "swapper friendly" won't mean a thing.

--

 

[samit700]

Yes I know the paging out depends on other processes. But I need to analyse the program assuming OS sets out a fixed amount of physical memory for it. Optimisations are very much possible by exploiting "spatial locality" , "temporal locality", and other principles. The program I am talking about is not a simple program but these are huge programs(>10000) so the effect from other processes is minimal. It is not just cuting/adding some lines of coding or 'messing data' but something else. This doesn't seem the right place to post such a question.

Anyways thanks for your reply.

 

[Salem]

> But I need to analyse the program assuming OS sets out a fixed amount of physical memory for it.
Which operating system does this?

> Optimisations are very much possible by exploiting "spatial locality" ,
Except if your program is calling malloc, there is no relationship between the results of malloc calls.
All your small blocks could be in one place, and all the large blocks in another.


--