现在让我们假设您已经缩小了应用程序中的典型瓶颈所在。就您所知，这可能是您为重新索引表而运行的批处理过程；它可能是在您的有效日期树上运行的 SQL 查询；它可能是数百个复合对象的 XML 编组。换句话说，你可能有这样的东西：
public Result takeAnAnnoyingLongTime(Input in) {
// impl of above
}
不幸的是，即使在您确定了瓶颈之后，您所能做的也只是逐渐消除它。没有简单的解决方案。
您如何衡量瓶颈的性能，以便知道您的修复正朝着正确的方向发展？
【问题讨论】：
标签： performance language-agnostic optimization
两点：
当心臭名昭著的“优化空闲循环”问题。 （例如，请参阅“Porsche-in-the-parking-lot”标题下的optimization story。）也就是说，仅仅因为例行程序需要大量时间（如您的分析所示），不要假设它会导致用户感知到的性能下降。
最大的性能提升通常不是来自对算法实施的巧妙调整或优化，而是来自于意识到完全有更好的算法。一些改进相对明显，而另一些则需要对算法进行更详细的分析，并且可能对所涉及的数据结构进行重大更改。这可能包括以处理器时间换取 I/O 时间，在这种情况下，您需要确保您不只优化其中一项措施。
回到所提出的问题，请确保您所衡量的任何内容都代表用户的实际体验，否则您的努力可能完全是浪费时间。
【讨论】：
【讨论】：
我会使用最初让我找到它们的相同工具/方法来测量它们。
也就是说，在所有地方都坚持计时和记录电话。如果数字开始下降，那么您可能做对了。
【讨论】：
正如msdn column 中提到的，性能调优就像画金门大桥的工作：一旦你完成了整个事情，是时候回到起点重新开始了。
【讨论】：
这不是一个难题。您需要了解的第一件事是，衡量性能并不是您发现性能问题的方式。知道某事有多慢并不能帮助您找出原因。你需要一个诊断工具，而且是一个好的工具。我在这方面有很多经验，this 是最好的方法。它不是自动的，但它在大多数分析器周围运行。
【讨论】：
这是一个有趣的问题。我想没有人知道答案。我相信问题的重要部分在于，对于更复杂的程序，没有人可以预测它们的复杂性。因此，即使您有分析器结果，也很难根据应该对程序进行的更改来解释它，因为您没有最佳解决方案的理论基础。
我认为这就是为什么我们的软件如此臃肿的原因。我们只进行优化，以便非常简单的案例可以在我们的快速机器上运行。但是，一旦将这些部分组合成一个大型系统，或者使用数量级更大的输入，使用的错误算法（在此之前在理论上和实践上都是不可见的）将开始显示其真正的复杂性。
示例：您创建了一个处理 Unicode 的字符串类。您可以在计算机生成的 XML 处理之类的地方使用它，而这并不重要。但是Unicode处理在那里，占用了部分资源。字符串类本身可以很快，但是调用百万次，程序就会很慢。
我相信当前大多数软件膨胀都属于这种性质。有一种方法可以减少它，但它与 OOP 相矛盾。有一本有趣的书There is an interesting book 介绍了各种技术，它是面向内存的，但大多数都可以恢复以提高速度。
【讨论】：
我会确定两件事：
1) 它的复杂度是多少？最简单的方法是绘制耗时与输入大小的关系图。 2）它是如何绑定的？是内存，还是磁盘，还是与其他进程或机器的IPC，还是..
现在第 (2) 点更容易解决和解释：如果您有更多 RAM、更快的机器或更快的磁盘，或者转移到千兆以太网等，很多事情都会变得更快。如果您发现自己的痛苦，您可以在硬件上投入一些资金以使其可以忍受。
【讨论】：