VC6 Profiler Problem: Spurious Function Calls

Question

I am running into the following issue while profiling an application under VC6. When I profile the application, the profiler is indicating that a simple getter method similar to the following is being called many hundreds of thousands of times:

int SomeClass::getId() const
{
   return m_iId;
};

The problem is, this method is not called anywhere in the test app. When I change the code to the following:

int SomeClass::getId() const
{
   std::cout << "Is this method REALLY being called?" << std::endl;
   return m_iId;
};

The profiler never includes getId in the list of invoked functions. Comment out the cout and I'm right back to where I started, 130+ thousand calls! Just to be sure it wasn't some cached profiler data or corrupted function lookup table, I'm doing a clean and rebuild between each test. Still the same results!

Any ideas?

Answer 1

I'd guess that what's happening is that the compiler and/or the linker is 'coalescing' this very simple function to one or more other functions that are identical (the code generated for return m_iId is likely exactly the same as many other getters that happen to return a member that's at the same offset).

essentially, a bunch of different functions that happen to have identical machine code implementations are all resolved to the same address, confusing the profiler.

You may be able to stop this from happening (if this is the problem) by turning off optimizations.

Answer 2

I assume you are profiling because you want to find out if there are ways to make the program take less time, right? You're not just profiling because you like to see numbers.

There's a simple, old-fashioned, tried-and-true way to find performance problems. While the program is running, just hit the "pause" button and look at the call stack. Do this several times, like from 5 to 20 times. The bigger a problem is, the fewer samples you need to find it.

Some people ask if this isn't basically what profilers do, and the answer is only very few. Most profilers fall for one or more common myths, with the result that your speedup is limited because they don't find all problems:

• Some programs are spending unnecessary time in "hotspots". When that is the case, you will see that the code at the "end" of the stack (where the program counter is) is doing needless work.

• Some programs do more I/O than necessary. If so, you will see that they are in the process of doing that I/O.

• Large programs are often slow because their call trees are needlessly bushy, and need pruning. If so, you will see the unnecessary function calls mid-stack.

Any code you see on some percentage of stacks will, if removed, save that percentage of execution time (more or less). You can't go wrong. Here's an example, over several iterations, of saving over 97%.