The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

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:

  1. gprof has 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).

  2. gprof always 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.

  3. 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 gcc that 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.

Obligatory Picture

An abstract representation of where you're coming from]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

Obligatory AI Disclaimer

No AI was used in the making of this site, unless otherwise noted.

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.