对于你复杂的算法,你如何衡量它的性能?

两点:

1. 当心臭名昭著的“优化空闲循环”问题。(例如,见 optimization story 在“停车场中的保时捷”标题下,也就是说,因为一个例行程序需要花费大量时间(如您的分析所示),不要认为它会导致用户感觉到的性能低下。

2. 最大的性能增益通常不是来自于算法的巧妙调整或优化,而是来自于意识到有一个更好的算法。一些改进是相对明显的,而另一些则需要对算法进行更详细的分析,可能还需要对所涉及的数据结构进行重大更改。这可能包括在处理器时间和I/O时间之间进行权衡,在这种情况下,您需要确保您没有只优化其中一个度量。

回到问题上来,确保你所测量的东西代表了用户的实际体验,否则你的努力完全是在浪费时间。

1. 简介它
2. 在探查器中找到顶行,尝试使其更快。
3. 简介它
4. 如果成功,转到1。如果不起作用,转到2。

我会用同样的工具/方法来测量它们,这些工具/方法可以让我首先找到它们。

也就是说,把时间和通话记录贴得到处都是。如果数字开始下降,那么你可能做的是对的。

如本文所述 msdn column ,性能调整与绘制金门大桥的工作相比:一旦绘制完整个过程,就应该回到开始,然后重新开始。

这不是个难题。首先你需要了解的是,衡量绩效并不是如何发现绩效问题。知道事情有多慢并不能帮你找出原因。你需要一个诊断工具,一个好的。我有很多这样做的经验,而且 this 是最好的方法。它不是自动的,但它在大多数分析器周围运行。

这是个有趣的问题。我想没人知道答案。我相信问题的主要部分是,对于更复杂的程序,没有人能够预测它们的复杂性。因此,即使您有profiler结果,也很难用应该对程序进行的更改来解释它,因为您没有最佳解决方案是什么的理论基础。

我想这就是为什么我们有如此臃肿的软件的原因。我们优化的目的只是为了让非常简单的案例能够在我们的快速机器上运行。但是,一旦你把这些片段组合成一个大系统,或者你使用数量级更大的输入,使用的错误算法(在那之前在理论和实践上都是看不见的)将开始显示它们真正的复杂性。

示例:创建一个字符串类,用于处理Unicode。您可以在计算机生成的xml处理等不重要的地方使用它。但是unicode处理在那里,占用了部分资源。字符串本身可以非常快,但调用它百万次,程序将是缓慢的。

我相信目前大多数的软件膨胀都是这种性质的。有一种方法可以减少它,但它与面向对象编程相矛盾。有一本有趣的书 There is an interesting book 关于各种技术,它是以内存为导向的,但大多数技术可以被还原以获得更高的速度。

我要确定两件事:

1)它的复杂性是什么?最简单的方法是绘制输入的时间和大小。 2)如何绑定?它是内存、磁盘还是与其他进程或机器一起使用的IPC,还是..

现在第(2)点更容易解决和解释:如果你有更多的ram或更快的机器或更快的磁盘,或转移到gig以太网等,很多事情都会变得更快。如果你确定你的痛苦,你可以投入一些钱到硬件,使它可以容忍。