当我使用YJP在我们自己的产品上执行cpu-tracing profile时，它确实很慢。
该产品在一台16GB的机器中运行，堆积为8GB，我使用研磨机进行小负载测试（例如10个研磨机螺纹），在分析过程中有大约7~10步。我有一个脚本用启动器启动产品，开始分析（使用控制器api），然后启动grinder来模拟用户操作。当所有操作完成后，脚本会告诉探查器停止分析并保存快照。
在分析过程中，对于研磨机测试中的每个步骤，完成需要超过100万毫秒。只需10个研磨机螺纹，整个分析通常需要10个多小时，每次运行测试10次。没有探查器，它会在500毫秒内完成。
所以...除了要分析的产品的问题之外，还有其他什么会影响cpu跟踪过程本身的性能吗？
答案 0 :(得分：1)
最后我使用了YourKit（v7.5.11，相当旧，当前版本为12）它有两个CPU分析设置：采样和跟踪，后者更快，更准确。由于跟踪被认为更准确，我自己使用它并观察到大幅放缓，尽管声称放缓是“平均”。然而，它远远低于你的结果：从2秒到10分钟。我的代码是计算引擎的一个片段，几乎没有IO，没有等待任何东西，只是读取输入，计算并将结果输出到控制台 - 所以整个减速来自分析器，没有外部影响。
回到你的问题：提到的选项 - samping vs tracing，会影响性能，所以你可以尝试采样。
现在我想起来了：可以设置YourKit，使其自动执行操作，例如定期制作快照或在内存不足，分析内存使用情况，对象分配，每个措施都会使分析速度变慢。也许您应该进行在线会话而不是脚本控制，以查看其真正的作用。
答案 1 :(得分：0)
根据一些Yourkit Doc：
尽管跟踪提供了更多信息，但它有其缺点。 首先，它可能会显着减慢配置文件的应用程序，因为 探查器在每个进入和退出时执行特殊代码 正在分析的方法。方法调用的次数越多 在配置文件应用程序中，跟踪时的速度越低 打开了。
第二个缺点是，由于此模式影响执行 配置文件应用程序的速度，在此模式下记录的CPU时间 可能不如采样记录的时间充足。 请使用 仅当您确实需要方法调用计数时才使用此模式。
此外：
使用采样时，探查器会定期查询堆栈 运行线程来估计代码中最慢的部分。没方法 调用计数可用，只有CPU时间。
当您的目标是找到和时，采样通常是最佳选择 发现性能瓶颈。通过采样，分析器增加了 几乎没有配置应用程序的开销。
此外，文档所说的“CPU时间”有点令人困惑，因为它也谈到了“挂钟时间”。 如果您正在进行任何I / O，等待，休眠或任何其他类型的阻塞，那么在挂钟时间而不是仅CPU时间上获取样本非常重要，因为假设阻塞时间无关紧要或者不可避免的。 幸运的是，这似乎是默认的（虽然它仍然有点不清楚）：
CPU采样的默认配置是测量墙壁时间 所有其他方法的I / O方法和CPU时间。
“使用预配置设置...”允许选择此项和其他 呈现。 （原文如此）
如果您的目标是尽可能快地使代码，不关注调用计数和测量“准确性”; 执行找出堆栈中的代码行的大部分时间，以及原因。 More on all that.