我有一些中型项目正在积极使用boost 库，因此在调试应用程序性能方面受到影响（Visual Studio 2008）。
我现在使用的解决方案是在Debug模式下开启函数内联，带来足够的性能，但肯定有一些缺点。
有谁知道如果我强制函数内联 (/Ob2) 切换，我会在调试能力方面失去什么？
也许有人对加速提升/其他模板库调试性能有任何其他想法？
【问题讨论】：
Render 方法，并发现 boost 方法有很多断言语句可以轻松地将 150 fps 降低到 15 =)
标签： c++ optimization boost debugging
在我看来，您可能不应该对调试版本进行性能测试。
保存调试版本以进行单元测试，以便您可以轻松发现问题，但真正的测试（功能和性能）可能应该在发布版本上。
毕竟这就是你的客户会运行的，对吧？
【讨论】：
我同意之前的回答，即您通常不应该真正关心调试构建的性能。测试在那里是因为我们需要它们......
但是，我是一个务实的程序员，我不使用 valgrinded 应用程序来运行我的测试是有原因的：我也不希望它们太慢，因为那时系统变得完全不切实际。
我看不出启用内联有什么问题，可以肯定调试器在找出产生代码的代码位置时可能会遇到一些问题，但它不会修改代码本身。
我还看到了部分调试版本。这个想法是关闭那些真正削弱程序的调试功能（如迭代器检查），以便手头的任务仍然可以接受性能。如果您发现哪些调试功能会减慢您的速度，它可能会在这里为您提供帮助。话虽如此，我从来没有遇到过 boost 的性能问题，但后来我用 gcc 编译它，我不知道在调试中是否保留了内联。
【讨论】：
assert 以及关闭边界/迭代器检查之前，我创建了一个 fast_debug 目标。但它没有内联。
我建议调试在调试模式下构建的应用程序，并在其内置发布模式时使用它（用于性能测试、一般用途等）。这样您就不必担心在调试时会丢失任何东西。
无论如何，在 Debug 中打开函数内联可能会在您遍历代码并且遇到对内联函数的函数调用时混淆调试器。但我从未测试过，所以我不确定。
【讨论】：
在调试和发布配置中都使用/Ob2。因此，当您对其进行调试时，它的行为方式与发布模式下的行为方式相同。
【讨论】：