Question

现在让我们假设您缩小了应用中典型瓶颈的位置。如您所知，可能是您为重新索引表而运行的批处理过程;它可能是运行在有效日期树上的SQL查询;它可能是几百个复合对象的XML编组。换句话说，你可能会有这样的事情：

public Result takeAnAnnoyingLongTime(Input in) {
   // impl of above
}

不幸的是，即使您确定了瓶颈之后，您所能做的就是消除它。没有简单的解决方案。

如何衡量瓶颈的性能，以便了解您的修复方向正朝着正确的方向发展？

Answer 1

两点：

谨防臭名昭着的“优化空闲循环”问题。（例如，请参阅标题为“保时捷停车场”标题下的optimization story。）也就是说，仅仅因为例行程序需要花费大量时间（如您的分析所示），请不要假设它对用户所感知的缓慢性能负责。
最大的性能提升通常不是来自对算法实现的巧妙调整或优化，而是来自于认识到完全有更好的算法。一些改进相对明显，而其他改进则需要对算法进行更详细的分析，并可能对所涉及的数据结构进行重大改变。这可能包括在I / O时间内处理处理器时间，在这种情况下，您需要确保您不仅仅优化其中一个措施。

将问题回到问题上，确保无论您测量的是什么，都代表用户实际体验的内容，否则您的努力可能会完全浪费时间。

Answer 2

Answer 3

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

即，在整个地方坚持计时和记录呼叫。如果数字开始下降，那么你可能正在做正确的事情。

Answer 4

正如本msdn column所述，性能调整与绘制金门大桥的工作相比较：一旦完成整个绘画的绘制，就应该回到起点并重新开始。

Answer 5

这不是一个难题。您需要了解的第一件事是，衡量性能并不是您发现性能问题的方式。了解某些东西有多慢并不能帮助你找出原因。你需要一个诊断工具，一个好的工具。我有很多这方面的经验，this是最好的方法。它不是自动的，但它会在大多数分析器周围运行。

Answer 6

这是一个有趣的问题。我认为没有人知道答案。我认为问题的重要部分在于，对于更复杂的程序，没有人能够预测它们的复杂性。因此，即使您有分析器结果，根据应该对程序进行的更改来解释它也是非常复杂的，因为您没有理论基础来确定最佳解决方案。

我认为这就是为什么我们拥有如此臃肿的软件的原因。我们只进行优化，以便在我们的快速机器上使用非常简单的情况。但是，一旦你将这些碎片组合成一个大型系统，或者你使用了数量级更大的输入，所使用的错误算法（直到理论上和实际上都是不可见的）将开始显示它们真正的复杂性。

示例：您创建一个处理Unicode的字符串类。你可以在计算机生成的XML处理中使用它，它实际上并不重要。但是，Unicode处理就在那里，占用了部分资源。就其本身而言，字符串类可以非常快，但称之为百万次，程序将很慢。

我认为目前大多数软件都属于这种性质。有一种方法可以减少它，但它与OOP相矛盾。有一本关于各种技术的有趣的书There is an interesting book，它以记忆为导向，但大多数都可以恢复以获得更快的速度。

Answer 7

我确定了两件事：

1）它的复杂性是多少？最简单的方法是绘制时间和输入大小的图表。 2）它是如何约束的？是内存，磁盘，还是IPC与其他进程或机器，或.. ..

现在点（2）更容易解决和解释：如果你有更多的RAM或更快的机器或更快的磁盘或转移到演出以太网等，很多事情会更快。如果你确定了你的痛苦，你可以把一些钱投入到硬件中以使其容忍。