Visual C++ Performance Pitfalls

When you develop a C++ application for Windows, it’s pretty convenient to open Visual Studio, click your way though the New Project wizard, and start coding. At first, you’ll build & test using the Debug configuration. Once your program becomes stable, and you’re ready to watch it run at top speed, you’ll switch to Release.

It’s easy to think that’s all you need to do. After all, when you look at default settings for Release builds, you’ll see all sorts of good stuff like “Maximize Speed” and “Whole Program Optimization”. That should take care of things, right?

Not exactly! It turns out that there are several pitfalls which can slow down the performance of your “optimized” C++ application. In some cases, significantly.

Take my previous post on Hash Table Performance Tests, where I compare the performance of various map containers. My first attempt to collect benchmarks for that post, using default Release settings, gave a completely different set of results compared to those that were eventually published:

The original results were completely skewed! If I had taken them at face value, I could have easily reached different conclusions about the containers being tested. For example, the two fastest containers, StringHashTable and the GCC hash table, actually ran the slowest, at first! And originally, the Python dictionaries beat half of the native C/C++ containers.

It took some analysis and tuning to discover what was going on. In the following series of posts, I’ll reveal the pitfalls I hit along the way, and illustrate the effect each one had on performance. I’m sure many Visual C++ programmers out there have fallen victim to the same pitfalls, to varying degrees.

Note: All tests were performed using Visual Studio 2008. Though this is an older version of Visual Studio, many development studios still use it today, and Visual Studio 2010 uses similar default settings.