January 2007 Archives

Need to do some performance analysis on the cheap?

Add some debug code to your app to write out the raw numbers you're interested in to a simple text file.

It's as simple as:

  FILE* perfdata = fopen("foo_perf.dat", "w");

  /* Simple header */

  fprintf("# Generated by myapp at %s", asctime(localtime(NULL)));

  fprintf("count rank score delta");

  for ( i = 0; ... )

  {

    /* something intensive here ... */

    fprintf( perfdata, "%u %d %f %f", count, gen->rank, gen->score, gen->delta );

  }

  fclose( fp );

Then you can use GNU R to plot the numbers over time, and quickly visualise what your code is doing.

> perf <- read.table("foo_perf.dat", header=TRUE)
> plot(perf)
> plot(perf$score ~ perf$delta)
> plot(perf$rank, type='l')

Enlightment!

You can also write out a timestamp (the canonical float time since epoch will do fine) and use the powerful time series tools too. Or simply subtract the value of the first timestamp entry from the column (eg. attach perf ; tstamp <- tstamp - tstamp[1]) and you have a convenient "zero time" and your x-axis becomes a measure of milliseconds since the event. Why, there's no end to the fun! :)

And R isn't just a publication-quality plotting tool -- it is a fully-blown programming language, with a massive array of statistical libraries. There's an excellent stats book that uses R (or S Plus) and shows how to get the most out of it - Statistical Computing by Crawley.

Oh, and I can't wait for X-Ray. Wow. I've used DTrace a few times, and it's awesomely powerful; it just takes a fair effort to learn, and even longer to learn how to use it effectively. It looks like Apple's sexy front-end will make this an incredibly useful tool.

I have been doing some serious hacking, fixing and refactoring on a codebase for genetics analysis. And I've needed tools to go beyond just sprinkling the usual calls to printf around the place to see what's going on. Hell, I've even fired up gdb once - but just to get a stack trace! This is the first of a sporadically released series on tools I've found useful. Hopefully they will distill the essential steps of using these tools, as well as expose some extremely useful but lesser known tricks to a wider audience (like the huge number of readers of this blog).

mtrace: Debugging malloc

The memory management provided by the standard libc library with GCC provides a very useful debugging mode, which can be used to detect memory leaks.

To start with, add:

#include <mtrace.h>

to the includes list at the top of your main module. Then add a call to mtrace() right at the very top of main, conditionally compiled, like:

int main( int argc, char* argv[], char* envp[] )
{
    /* locals etc ... */

#ifdef MYAPP_DEBUG_ALLOC

    mtrace();

#endif /* MYAPP_DEBUG_ALLOC */

    /* do something funky... */

    return 0;

}

This will install special handlers to intercept calls to malloc/free et al. Then you can enable this feature as required.

At runtime, the MALLOC_TRACE environment variable must be set to the name of the output file to store the extra trace data. If this is not set, mtrace will do nothing!

You can run your program like this:

% MALLOC_TRACE=myapp.mtrace ./myapp -f 123 foo.dat

Once your program has terminated, you can then go ahead and analyse the output using the supplied mtrace tool. You point it to your binary (so it can pull out the symbol table) and to the saved .mtrace file (from above) and - behold! - a big list of all your leakage.

Now all you have to do is tidy up those calls to free!

Stay tuned for the next exciting installments on:

• gcov
• gprof
• cflow
• Valgrind
• and probably not many more...