C++ optimization question

Question

Hello!

I have some mid-large project that is actively using boost libraries and, hence, suffers in terms of Debug application performance (Visual Studio 2008).

Solution that I use right now means turning on function inlining even in Debug mode, which brings enough performance, but should definitely have some drawbacks.

Does anyone know what will I lose in terms of debugging capabilities if I force function inlining (/Ob2) switch?

Maybe someone have any other ideas about speeding up boost / other template libraries Debug performance?

Answer 1

I would suggest debugging the application built in Debug mode and using it when its built in Release mode (for performance tests, general usage etc.). That way you won't need to worry about losing anything while debugging.

Anyway, turning on inlining of functions in Debug might confuse the debugger when you traverse the code and you encounter a function call to a function that was inlined. But i never tested that, so i'm not sure.

Answer 2

In my opinion, you should probably not be performance-testing your debug release.

Save the debug release for unit testing so you can easily find problems but real testing (functionality and performance) should probably be on the release version.

That's what your customers will be running after all, right?

Answer 3

Use /Ob2 in both Debug and Release configurations. So when you debug it, it would behave the same way as in release mode.

Answer 4

I agree with the previous answers that you should not really care about the performance of your debug build in general. The tests are there because we need them...

However, I am a pragmatic programmer, and there is a reason I do not use a valgrinded application to run my tests: I don't want them to be too slow either, because the system becomes completely impractical at that point.

I don't see anything wrong with enabling inlining, sure the debugger might have some issues picking out the place in code which produced the code, but it doesn't modify the code itself.

I have also seen partial-debug builds. The idea is to turn off those debug features which really cripple the program (like iterator checking) so that performance remains acceptable for the task at hand. It could potentially help you here, if you figure which debug features slows you down. That being said I have never had performance issues with boost, but then I compile it with gcc and I don't know if inlining is preserved or not in debug.