0

我正在开发一个需要快速运行的处理插件（性能很关键 - 至少在某种程度上）我有一个处理部分的引擎和一个围绕它的外壳来处理：

  • 通讯
  • 消息
  • 图形用户界面
  • 日志
  • 调用引擎

以下是我对 Visual Studio 的分析： 在此处输入图像描述

百分比与作为主机的进程上的样本相关。

  • 这个主机做的事情很少，只使用了 12.19% 的样本。
  • 我的 shell 只使用 50%
  • 引擎（由外壳调用）仅使用 12.8%。

如您所见，我的 shell 中的处理部分（BaseProcessor::process 和所有包含的函数调用）大约是 15%，仅比引擎本身高 3%。这意味着我的“外壳”的开销不是太大。

但是我的“外壳”在有关并发的功能上花费了更多时间（排他性和包容性）。这些函数是 VS CRT 代码中threadproxymain代码的一部分。

这是什么concurrency::details东西，我该如何解决

我正在使用std :: atomic和futures，并且我在工作线程AFAIK中睡觉。

谢谢你的建议！

[编辑]

问题，经过几次测试（有更多的样本来提高 presision），碰巧出现在一个调用这个的代码中，这个视图中没有显示，但是专有的示例/模块帮助我找到了哪个 DLL 正在使用所有这些 CPU。之后，我使用函数详细信息视图发现调用是从 CLogBuffers 发出的（在此视图中包含 5%）

谢谢你指出我的错误

4

1 回答 1

3

您共享的只是数据的图片，而不是相关数据。从查看按 Inclusive 排序的函数列表可以看出，一些函数位于堆栈的顶部（如 Dispatch、ThreadProxyMain 等）并且将在每个堆栈中，因此包含的计数很高但排他的计数非常低。这里没有什么新东西，总是意料之中的，并不表示有任何问题。

几个似乎可以做任何工作的函数是：GetNextVirtualProcess、FindVirtualProcessor、StealLocalRunnable 和 SearchCacheLocal。只能猜测，只有一张图片可以看，但看起来你自己的代码并没有真正做任何事情，唯一要在性能数据中捕获的是代码何时产生等。

perf analysys 中有更多视图（蝴蝶视图是一个很好的例子），这将有助于查明问题（如果确实存在）。就目前情况而言，我真的没有在您发布的图片中看到任何性能问题。也是一个很小的样本，在1000个样本基本上是无关紧要的。您是否以足够的分辨率捕获了在严重负载下、足够的时间和足够的分辨率下的过程？

于 2013-09-22T12:51:57.393 回答