在这个网站上已经有很多性能问题了，但是在我看来，几乎所有的问题都是非常具体的，而且相当狭窄。几乎所有人都重复了避免过早优化的建议。
我们假设:
代码已经正常工作了 所选择的算法对于问题的环境已经是最优的 对代码进行了测量，并隔离了有问题的例程 所有优化的尝试也将被衡量，以确保它们不会使事情变得更糟
我在这里寻找的是策略和技巧，在一个关键算法中，当没有其他事情可做，但无论如何都要挤出最后百分之几。
理想情况下，尽量让答案与语言无关，并在适用的情况下指出所建议的策略的任何缺点。
我将添加一个带有我自己最初建议的回复，并期待Stack Overflow社区能想到的任何其他东西。
当前回答
虽然我喜欢Mike Dunlavey的回答，但事实上这是一个很好的答案，并且有支持的例子，我认为它可以简单地表达出来:
首先找出哪些事情最耗费时间，并了解原因。
它是时间消耗的识别过程，可以帮助您了解必须在哪里改进算法。这是我能找到的唯一一个全面的语言不可知论答案，这个问题已经被认为是完全优化的。同时假设您希望在追求速度的过程中独立于体系结构。
因此，虽然算法可能被优化了，但它的实现可能没有。标识可以让您知道哪个部分是哪个部分:算法或实现。所以，占用时间最多的就是你审查的首选对象。但是既然你说你想把最后的%挤出来，你可能还想检查一下较小的部分，那些你一开始没有仔细检查过的部分。
最后，对实现相同解决方案的不同方法的性能数据进行一些尝试和错误，或者可能的不同算法，可以带来有助于识别浪费时间和节省时间的见解。
HPH, asoudmove。
其他回答
建议:
Pre-compute rather than re-calculate: any loops or repeated calls that contain calculations that have a relatively limited range of inputs, consider making a lookup (array or dictionary) that contains the result of that calculation for all values in the valid range of inputs. Then use a simple lookup inside the algorithm instead. Down-sides: if few of the pre-computed values are actually used this may make matters worse, also the lookup may take significant memory. Don't use library methods: most libraries need to be written to operate correctly under a broad range of scenarios, and perform null checks on parameters, etc. By re-implementing a method you may be able to strip out a lot of logic that does not apply in the exact circumstance you are using it. Down-sides: writing additional code means more surface area for bugs. Do use library methods: to contradict myself, language libraries get written by people that are a lot smarter than you or me; odds are they did it better and faster. Do not implement it yourself unless you can actually make it faster (i.e.: always measure!) Cheat: in some cases although an exact calculation may exist for your problem, you may not need 'exact', sometimes an approximation may be 'good enough' and a lot faster in the deal. Ask yourself, does it really matter if the answer is out by 1%? 5%? even 10%? Down-sides: Well... the answer won't be exact.
缓存!要使几乎任何事情都变得更快，一个便宜的方法(在程序员的努力中)是在程序的任何数据移动区域添加缓存抽象层。无论是I/O还是只是传递/创建对象或结构。通常，向工厂类和读取器/写入器添加缓存是很容易的。
有时缓存不会给你带来太多好处，但这是一种简单的方法，只需添加缓存，然后在没有帮助的地方禁用它。我经常发现这样做可以获得巨大的性能，而无需对代码进行微观分析。
你在什么硬件上运行?您是否可以使用特定于平台化的优化(如向量化)? 你能找到更好的编译器吗?比如从GCC换成Intel? 你能让你的算法并行运行吗? 可以通过重新组织数据来减少缓存丢失吗? 可以禁用断言吗? 对编译器和平台进行微优化。在if/else语句中，把最常见的语句放在前面
当你不能再提高表现时，看看你是否可以提高感知的表现。
您可能无法使您的fooCalc算法更快，但通常有一些方法可以使您的应用程序对用户的响应更快。
举几个例子:
预测用户将要做什么 请求并开始着手这项工作 在那之前 将结果显示为 它们是进来的，而不是同时出现的 在最后 精确的进度计
这些不会让你的程序更快，但可能会让你的用户对你的速度更满意。
When you get to the point that you're using efficient algorithms its a question of what you need more speed or memory. Use caching to "pay" in memory for more speed or use calculations to reduce the memory footprint. If possible (and more cost effective) throw hardware at the problem - faster CPU, more memory or HD could solve the problem faster then trying to code it. Use parallelization if possible - run part of the code on multiple threads. Use the right tool for the job. some programing languages create more efficient code, using managed code (i.e. Java/.NET) speed up development but native programing languages creates faster running code. Micro optimize. Only were applicable you can use optimized assembly to speed small pieces of code, using SSE/vector optimizations in the right places can greatly increase performance.
