我目前正在重新编写一个编译时正则表达式库，这是我以前编写的，但是新版本的构建时间比旧版本慢得多（在我的基准测试中，新版本的构建时间约为7.5秒，而旧版本的构建时间约为2.5秒）。
因此，为了分析构建过程，我使用clang的-ftime-trace创建了编译火焰图：
clang++ -I. -std=c++20 -ftime-trace -c main.cpp # Old library version
clang++ -I. -std=c++20 -ftime-trace -c main2.cpp # New library version正如预期的那样，该标志会降低编译速度，但问题是它会反转该行为：新版本的建立在~ 12 s，而旧的现在建立在~ 16 s。
虽然我仍然可以在技术上使用新构建的火焰图来优化它，但我想知道火焰图的生成对构建过程的性能和表示时间有多大影响。由于两个库有很大的不同，上面的结果表明，一些没有标记的快速构建代码在火焰图生成时变得非常慢。
有人知道如何处理这个问题吗？
1条答案
按热度按时间w8rqjzmb1#
有人知道如何处理这个问题吗？
这没什么好处理的。使用任何类型的分析器的目的都是为了找到速度下降的地方。插桩代码的原始性能与找到瓶颈"无关"，因为我们的目标是找到"未插桩"版本中的瓶颈。分析器运行得多快不是关键;剖析器对 * 优化 * 版本运行速度的描述才是最重要的。
也就是说，你不应该仅仅因为插桩版本的整个运行时发生了不成比例的变化，就低估插桩运行所提供的信息。你要寻找的是优化代码中的哪些进程花费了多少时间。图表应该告诉你这一点。