On Mon, 2014-04-28 at 14:42 -0400, Rafael Schloming wrote: > On Mon, Apr 28, 2014 at 2:37 PM, Andrew Stitcher <[email protected]>wrote: > > > On Mon, 2014-04-28 at 13:34 -0400, Alan Conway wrote: > > > I wouldn't instrument the code for this, there are tools that can > > > measure this kind of thing without code changes. > > > > > > valgrind has cachegrind which profiles calls in general and can be used > > > to identify the sources of malloc calls - there's a nice visualization > > > tool kcahcegrind for looking at the output. > > > > > > valgrind also has a memory profiler called massif which I haven't really > > > used. > > > > > > systemtap provides a general scripting language that you can use to > > > intercept malloc calls. There are a bunch of memory related scripts > > > pre-packaged > > > http://sourceware.org/systemtap/examples/keyword-index.html#MEMORY > > > > > > There are surely others... > > > > These are great tools that work really well and I've enjoyed using them > > myself on big heavy weight platforms like Linux. However on the little > > embedded platforms the OP was asking about there is no real alternative > > but to use something much lighter weight. For example some simple built > > in instrumentation. Perhaps built in to the linked-in libc runtime > > library though so it needn't necessarily require code changes to Proton. > > > > Of course if you can run the initial scenario on Linux under > > valgrind/systemtap etc. first then that will give you an idea what you > > need to go and change, but you will still need the target machine > > instrumentation in the end.
Fair point. Perhaps an LD_PRELOAD library that replaces malloc & free and uses glibc backtraces? No impact on the proton code and would be useful for other things. But surely there's one out there in open-sourceland already? > I'd also like to be able to track peak memory usage as well as > mallocs/frees under various load scenarios, and I suspect valgrind would > add too much overhead for that. Test your suspicions before you invest too heavily in knitting your own. I was able to get a lot of useful results from such tools working on the 0-10 protocol with Qpid.
