性能受文件解析线程影响可能是由于std :: string堆分配？

Question

我有一个使用OpenFrameworks的实时3D程序，在正常情况下在单个线程上以60 fps的速度轻松运行。我有一个第二辅助线程，当工作时导致我的主线程更新率下降并间歇性停止。

为了调试这种情况，我试图通过以下方式来解决问题：

1. 主线程在我的测试条件下工作相对较少，并且在辅助线程运行时达到2000fps。

2. 第二个线程以连续循环方式运行并尝试通过以下

   加载大型（20Meg）xml文件

   while (true) 
   {
       ofXml test;
       test.load("bigfile.xml");
   }
   

3. 主线程和辅助线程之间没有编程共享资源，并且两个线程中都没有锁/互斥锁。

分析似乎给了我一个可能的答案，看起来辅助线程上的堆分配和解除分配可能会淹没堆分配器，因此主线程分配/解除分配正在减慢。

我使用了一个“非常困”的采样分析器，在辅助线程暂停时，先将我的主线程分析30秒，然后重新开始。

当辅助线程暂停运行时，顶部独占％函数如下所示，并查看新建时间的堆栈：





现在在辅助线程激活时运行相同：





这似乎表明std::string分配在辅助线程中的堆分配正在减慢，并且可能是导致减速和停顿的原因。这听起来不对吗？ ，或者我可能会遗漏一些东西。在尝试使用std::string重写代码之前，我想确保我的分析是正确的。

Answer 1

因为它允许您在辅助线程上查看单个调用堆栈，所以这些是要查看的内容。例如，您展示的那个超过20％的时间是在重新分配字符串的过程中，可能是为了增长它们。如果你也看一下其他的堆栈样本，我敢打赌他们也在发展字符串（只是不在new）。如果是这样，这意味着在增长字符串中花费的百分比更高。如果是这样，那么你可以做的任何事情都可以帮助增加默认字符串分配或增长大小。

（顺便说一句，你可以从中看到，专属时间没有帮助。包容时间就是你所需要的，但即便如此，也不像简单地检查堆栈样本那样有用，这样你就可以看出为什么它会做什么＆它＃39;在做什么。 这就是this technique如此有效的原因。 ）