|
From: Cole, D. <dc...@in...> - 2011-06-03 19:21:42
|
Hello, I have used valgrind in the past to profile code memory usage post-mortem. I know valgrind can be used to detect problems and usage if memory management functions. Is it possible to use valgrind to *Monitor* memory usage in real-time? I would like to know which functions are allocating how much? If this is possible, how much of a performance hit will I take? I am hoping to find some lightweight tools for doing this. I am assuming for this to work, you'd have to be running with symbols (debug mode) for both the code I have, and any libraries it may be linking. Is this assumption accurate? Thanks! |
|
From: Peter E. <Pet...@ce...> - 2011-06-03 22:05:27
|
Hi Derek, On Fri, Jun 03, 2011 at 07:21:25PM +0000, Cole, Derek wrote: > I have used valgrind in the past to profile code memory usage > post-mortem. I know valgrind can be used to detect problems and > usage if memory management functions. Is it possible to use valgrind > to *Monitor* memory usage in real-time? I would like to know which > functions are allocating how much? If this is possible, how much > of a performance hit will I take? I am hoping to find some lightweight > tools for doing this. I am assuming for this to work, you'd have > to be running with symbols (debug mode) for both the code I have, > and any libraries it may be linking. Is this assumption accurate? If you are looking for fairly lightweight tool to understand memory allocation patterns, you might take a look at igprof: http://igprof.sourceforge.net/ It doesn't detect errors like valgrind memcheck, but in its memory profiling mode does provide the allocation patterns in a fairly lightweight way. For our 64bit applications (which unfortunately are quite heavy allocators), the slowdown in memory profiling mode is a factor of 3. For 32bit applications it was less, perhaps about 50%. What you see depends of course on your application and how much it allocates. (The separate performance profiling mode of igprof adds very little overhead for either 32bit or 64bit applications.) Neither mode require recompilation or building with debugging symbols. Pete ------------------------------------------------------------------------- Peter Elmer E-mail: Pet...@ce... Phone: +41 (22) 767-4644 Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland ------------------------------------------------------------------------- |