Wednesday, April 10, 2013
Three issues with profiling code
I had three issues with profiling code at The Corporation. I manged to solve all three:
gprofhas issues dealing with multithreaded code—namely, it doesn't handle it very well. I did find a fix for the issue, and while it's a small bit of code, explaining why it works is more than I care to get into at this point in time (it comes down to—if you know why you need this, then you'll understand what it does).
gprofalways uses the same file for output,
gmon.out, regardless of the program name. This is okay when you are working with one program. It's not okay if you are working with multiple programs (right now, I'm testing two programs, running one instance of one, and up to 200 instances of another one).
But thankfully, there is a fix for this issue as well. You just need to set an environment variable to a unique name, and the output file will be that name with the process-id. Since I run all these programs from a Lua script, it's easy enough to ensure that this environment variable is created.
Compiling all these programs to be “profile-enabled.” Yes, I could modify the
Makefiles, but some third-party libraries use their own build system (and depending on the programs, libraries and platforms, I have to edit one of sixteen or so files). But I don't always want a “profile-enabled” build (which would mean re-editing a bunch of files). What I want is a simple way to get a “profile-enabled” build, or not.
Yes, I could take the time to extend the
Makefiles and custom build systems to include a “profile-enable” option, but frankly, breaking the build is scaring me off that route. So I decided that for me, the simplest thing that could possibly work would be to write a wrapper around
gccthat would add the proper option (and remove conflicting options) to do a “profile-enabled” build (based on an environment variable).
The code is basically, add the (and remove) the appropriate option(s) to the command line, then run the compiler.
It beats editing a ton of files.