现在我们假设您已经缩小了应用中典型瓶颈的位置。对于你所知道的，它可能是你运行重新索引你的表的批处理过程;它可能是SQL查询运行在有效日期的树上;它可能是几百个复合对象的XML编组。换句话说，你可能有这样的事情：对于您复杂的算法，您如何衡量其性能？
public Result takeAnAnnoyingLongTime(Input in) {
// impl of above
}
不幸的是，你已经确定你的瓶颈，甚至后，所有你能做的就是芯片不停。没有简单的解决方案可用。
你如何衡量瓶颈的性能，以便你知道你的修复方向是朝着正确的方向发展的？
我会使用相同的工具衡量他们/，让我的方法来找到他们首先。
即，坚持时间安排和日志记录呼吁各地。如果数字开始下降，那么你可能会做正确的事情。
正如msdn column中提到的那样，将性能调整与涂装金门大桥的工作进行比较：一旦完成绘画整个事情，现在是时候回到开始并重新开始。
两点：
小心臭名昭著的 “优化空闲循环” 的问题。 （例如，在“保时捷停车场”标题下看到optimization story）。也就是说，仅仅因为例行程序花费了大量时间（如您的分析所示），请不要认为它是负责任的对于用户感知的缓慢性能。
最大的性能提升往往不是来自于对算法实现的巧妙调整或优化，而是因为认识到完全有更好的算法。一些改进相对明显，而其他改进则需要对算法进行更详细的分析，并可能对所涉及的数据结构进行重大改变。这可能包括将处理器时间换成I/O时间，在这种情况下，您需要确保您没有只优化其中一种措施。
回到所问的问题，确保你测量的任何东西都代表了用户的实际体验，否则你的努力可能完全浪费时间。
这是一个有趣的问题。我不认为有人知道答案。我相信问题的重要部分是对于更复杂的程序，没有人能预测它们的复杂性。因此，即使您拥有分析器结果，也应该根据对程序所做的更改来解释它，这非常复杂，因为您没有理想的解决方案。
我认为这是我们拥有如此臃肿的软件的原因。我们只进行优化，以便在我们的快速机器上运行相当简单的案例。但是一旦你把这些碎片放到一个大的系统中，或者你使用了更大量的输入，使用了错误的算法（直到那时在理论上和实际上都看不见）才会开始显示它们真正的复杂性。
示例：您将创建一个处理Unicode的字符串类。您可以在计算机生成的XML处理的地方使用它，但这并不重要。但是Unicode处理就在那里，占用了部分资源。本身，字符串类可以非常快，但称它为百万次，程序将会很慢。
我相信目前软件的大部分膨胀都属于这种性质。有一种方法可以减少它，但它与OOP相矛盾。关于各种技术，有一本有趣的书There is an interesting book，它是面向内存的，但其中大多数可以恢复到更快的速度。
我想确定两件事：
1）它有多复杂？最简单的方法是绘制输入的时间经文大小。 2）它是如何绑定的？是内存，还是磁盘，还是带有其他进程或机器的工控机，或者是其他进程或机器，或者是其它进程或机器，或者是其他进程或机器的IPC，或者是..
现在点（2）更易于解决和解释：如果有更多的RAM或更快的机器，更快的磁盘或移动到演出以太网等。如果你发现自己的痛苦，那么你可以在硬件上投入一些资金以使其可以忍受。
这不是一个难题。你需要了解的第一件事是测量性能不是你如何发现性能问题。了解速度有多慢并不能帮助你找出原因。你需要一个诊断工具，并且是一个好的工具。我有很多经验，this是最好的方法。它不是自动的，但它围绕大多数轮廓仪运行。