Reputation: 1125
I'm using IBM Quantify to try to compare run time of different function calls in my program, but a headache is many function calls has DEBUG macro outputing stuff like this,
#ifdef DEBUG
cout << "Value is "<< value << endl;
#endif
When I do profiling I found these IO operations take most of time, and of course what I care is the real run time for the released version. Is there anything I can do to get a more accurate result for released version instead of manually removing these DEBUG macros?
I'm building the code using Visual Studio compiler in debug mode, when I build it with -o option, it cannot be run for profiling saying no debug information available.
Upvotes: 0
Views: 240
Reputation: 40649
I separate the problem into two parts, overall measurement of time, and then getting percents. Overall measurement is simple - give it enough work to take at least several seconds, and then just time it. If necessary just loop it 10 or 1000 times.
Then to get percents, while it's running, capture some stackshots. You could use a stack-grabber or just hit it (repeatedly) with the pause button and copy-paste the call stack. The percent of time a function is active is the percent of time it is on the stack, which is roughly the percent of stack traces containing it. This does not tell you about functions that only take a small percent, but changing those would not save you much.
Upvotes: 0
Reputation: 28829
You'll definitely want to use a release build for profiling. You can modify the project settings to have PDBs emitted for release builds.
Upvotes: 3