Basically, how I profile a game that have multithreading and script interpreter? (Lua in my case)

I have no idea of where to look for that.

Also it would be nice to be able to profile code that resemble somehow the release code, my "debug" binary is about 12 times bigger...

EDIT: My game was made with C++, compiled with GCC, runs on Windows and GNU/Linux for now, compiled natively (ie: MingW on Windows, regular GCC on GNU).

  • 1
    \$\begingroup\$ What platform? PC? Mac? Linux? Console/handheld? If PC/Mac/Linux, what make of processor on your dev box (helps for specific suggestion)? Also, what programming languages (aside from lua) and compilers? \$\endgroup\$
    – leander
    Commented Aug 13, 2010 at 19:39
  • \$\begingroup\$ Are you asking for home-brew profilers or just any profile-tool? \$\endgroup\$
    – Simon
    Commented Aug 13, 2010 at 19:59
  • \$\begingroup\$ Profiling a debug build would be a fairly pointless exercise anyhow - regardless of size. \$\endgroup\$
    – Kaj
    Commented Aug 13, 2010 at 20:00
  • \$\begingroup\$ @Kaj: hehe, except when your debug build gets too slow to be reasonably usable =) I've been threatening to get out the tools for our platformer engine's debug build, which has over the last few months picked up an abysmal slowdown in debug... such that even coders aren't running in debug anymore with the extra asserts, memory fencing, and the like, which is leaving us open to a lot more bugs than usual. \$\endgroup\$
    – leander
    Commented Aug 13, 2010 at 20:09
  • \$\begingroup\$ Make different flags for disabling different debug levels/features? \$\endgroup\$
    – Kaj
    Commented Aug 13, 2010 at 20:46

2 Answers 2


I have a home-made profiling system that consists of profile-probes that I've injected on a lot of none-inner-loop places in my code. The probes are initially disabled and I just enable the ones that I want to check up on. The system simply throws out the information to a .txt file (or a network stream) that I then use another language to parse the output from and present the data in a more user-friendly way. The probes are globally initialized upon creation and only when recording them creates any data.

The benefits of this is:
* While enabled (even in release builds), the system is light on cpu cycles and you'll most likely not notice any performance hit while all probes are disabled.
* While disabled (final build), the system is reduced to 0 cost (like most home-brewn profile-systems).
* It can measure time, hits, record callstacks, print variables, so it's flexible and can be used for most debugging that you'll need.
* It's dynamic, you can get exactly the information that you want from it.

On the negative side: It took nearly 2 days to implement so it's fairly complex. It'll likely make up for that time though.

Examples for usage:
* Timescoping
* Memory allocations (sizes, names, etc).
* Resource tracking
* Debugging (conditional prints).

  • \$\begingroup\$ I use the timer approach a lot (prefer it over a regular profiler to get an overall feel). It is less useful if you can't isolate your threads (on a single core) though as you can't truly know what you are timing. \$\endgroup\$
    – Kaj
    Commented Aug 15, 2010 at 16:47
  • \$\begingroup\$ There is a timer included in it. It also includes thread-id for when the probe was called etc. \$\endgroup\$
    – Simon
    Commented Aug 16, 2010 at 7:49

Until we have a few more specifics on your platform/OS/compiler, it's going to be hard to answer, but in the mean time, look at this answer to "In general how often and when should I optimize my code?" for some generic suggestions.

Most of these suggestions will work equally well in optimized (release) or non-optimized (debug) builds.

(I'll return and update this answer with more specific tools and ideas if you update the question with more details.)

Edit: okay, more specific suggestions.

Take a two-pronged approach. One, do exactly what Simon is suggesting -- build a lightweight "stopwatch" timer into your code. It doesn't have to be pretty to start with -- as my link above suggests, you can always "drill down" from coarse info to finer-grained info.

Second, take advantage of the free (gratis) tools. Even if you don't get exactly the info you want, scope out a sampling profiler such as AMD CodeAnalyst. This shouldn't have problems with threads, and should be capable of giving you a "code was often in this place" readouts, or even full stack traces. While it may be a little harder to reason about the masses of data you'll get here, chances are you'll see something, and it has the advantage of being non-intrusive. If you have an AMD processor CodeAnalyst will even do the performance counter stuff for you, giving you access to e.g. cache miss and branch prediction info.

It might be fun to take valgrind's cachegrind, callgrind, or massif across the project. This is definitely going to slow things down but you may learn a lot. The valgrind memcheck module is worth knowing about too.

You may also want to investigate the GCC's intrusive gprof. Sampling profilers are generally observed to be a better idea (they don't alter what they're looking at quite as much), but you may also learn something from gprof's complete instrumentation that you couldn't see using sampling.

None of this gives you great visibility into the lua parts. You'll get stack samples or call info from within lua, and you might be able to infer what it's doing with per-line or per-instruction samples. But it may not be easily decomposable into "which scripts took the most time" or "which line of this script is giving us the most trouble". For that you'll need to either look into a commercial lua engine, or just extend your stopwatch tool a bit...

(There was a game middleware company offering a fully custom lua engine with profiling and debugging tools, can't find them now... There's also lua profiler, googling around a bit. Not sure if it would fit the bill, but it seems like there are others too.)

If you're willing to take the time to play with CodeAnalyst, valgrind, or gprof, chances are you'll learn something -- if not about your code, then about profiling in general, which you might use to enhance your own custom solution. =)

  • \$\begingroup\$ I tried using CodeAnalyst, but for some reason it kept complaining it did not found profile info, and refused to work :/ (that was a long time ago, mind you... not after your really good reply) \$\endgroup\$
    – speeder
    Commented Aug 15, 2010 at 18:18
  • \$\begingroup\$ Yeah, I definitely have had issues with CodeAnalyst crashing in the past. It has gotten better lately. Try it on whichever OS you haven't already? There are both Linux and Windows versions. You might also want to see if you can net Vtune or one of the other commercial products (with an educational discount, maybe?). I'm pretty sure there are a handful of other gratis sampling profilers out there, too. \$\endgroup\$
    – leander
    Commented Aug 15, 2010 at 21:48
  • \$\begingroup\$ I tired again, the exact reason I don't use it, is that it keeps complaining that it don't find the source, and I have no idea on how to fix it (even after reading the manual, googling, that btw only find one match for the error phrase, and the resulting page is in russian...) \$\endgroup\$
    – speeder
    Commented Aug 16, 2010 at 3:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .