1

我正在寻找好的（最好是即插即用的）解决方案来对我正在开发的软件进行诊断。我正在开发的软件有几个需要大量计算资源的组件，因此我们试图捕捉这些组件的性能有两个原因：1）估计所需的计算资源，从而估计运行软件的成本，以及 2）量化组件的“改进”是什么（即，如果我们修改代码并提高速度，那么它就是一种改进）。我们的应用程序由搜索引擎加上许多其他组件组成，了解搜索引擎的速度对最终用户也很重要。

似乎很难找到解决方案，因为我不确定如何正确定义我的问题。但到目前为止我发现的似乎是基本的错误记录技术。一个旨在从数据中运行统计数据（例如统计回归）的解决方案将是最好的。也许单元测试框架有内置的测试计时器，但我们需要从应用程序的实时运行中捕获数据，以应对众多不同的场景。

所以真的有两个问题：

1）这些测试有预定义的解决方案吗？

2）对这类数据进行统计回归有什么好的参考吗？假设我们捕获了脚本的执行时间和输入数据（例如查询）的大小。我们可以对数据大小进行时间回归，以了解更改数据大小对执行时间的影响。但是这些类型的回归很棘手，因为不清楚所有相关变量是什么。任何对分析性能数据的参考都会非常好，我相信对很多人都有好处！

谢谢马特

4

1 回答 1

0

Big apps like these are going to be doing a lot of non-CPU processing, so to find optimization points you're going to need wall-clock-based, not CPU-based, sampling.

gprof and some others only sample on CPU time, so they cannot see needless I/O or other system calls. If you do manage to find and remove CPU-intensive performance problems, the I/O-intensive ones will only become a larger fraction of the time.

Take a look at Zoom. It's a stack sampler that reports, by line of code, the percent of wall-clock time that line is on the stack. Any code point worth optimizing will probably be such a line. It also has a nice butterfly view for browsing the call graph. (You don't want the call graph as a whole. It will be a meaningless rat's nest.)

于 2011-05-20T17:26:18.390 回答