在这个网站上已经有很多性能问题了，但是在我看来，几乎所有的问题都是非常具体的，而且相当狭窄。几乎所有人都重复了避免过早优化的建议。
我们假设:
代码已经正常工作了 所选择的算法对于问题的环境已经是最优的 对代码进行了测量，并隔离了有问题的例程 所有优化的尝试也将被衡量，以确保它们不会使事情变得更糟
我在这里寻找的是策略和技巧，在一个关键算法中，当没有其他事情可做，但无论如何都要挤出最后百分之几。
理想情况下，尽量让答案与语言无关，并在适用的情况下指出所建议的策略的任何缺点。
我将添加一个带有我自己最初建议的回复，并期待Stack Overflow社区能想到的任何其他东西。
当前回答
最后几个%是一个非常CPU和应用程序依赖的东西....
缓存架构不同，有些芯片有片上内存 你可以直接映射，ARM的(有时)有一个矢量 单位，SH4是一个有用的矩阵操作码。有GPU吗 也许一个着色器是可行的。TMS320非常 对循环中的分支敏感(因此分离循环和 如果可能的话，将条件移到室外)。
名单在....上但这类事情真的是 最后的手段……
编译x86，并运行Valgrind/Cachegrind对代码 进行适当的性能分析。或者德州仪器的 CCStudio有一个贴心的侧写器。然后你就知道在哪里了 关注……
其他回答
虽然我喜欢Mike Dunlavey的回答，但事实上这是一个很好的答案，并且有支持的例子，我认为它可以简单地表达出来:
首先找出哪些事情最耗费时间，并了解原因。
它是时间消耗的识别过程，可以帮助您了解必须在哪里改进算法。这是我能找到的唯一一个全面的语言不可知论答案，这个问题已经被认为是完全优化的。同时假设您希望在追求速度的过程中独立于体系结构。
因此，虽然算法可能被优化了，但它的实现可能没有。标识可以让您知道哪个部分是哪个部分:算法或实现。所以，占用时间最多的就是你审查的首选对象。但是既然你说你想把最后的%挤出来，你可能还想检查一下较小的部分，那些你一开始没有仔细检查过的部分。
最后，对实现相同解决方案的不同方法的性能数据进行一些尝试和错误，或者可能的不同算法，可以带来有助于识别浪费时间和节省时间的见解。
HPH, asoudmove。
调整操作系统和框架。
这听起来可能有点夸张，但可以这样想:操作系统和框架被设计用来做很多事情。您的应用程序只做非常具体的事情。如果你能让操作系统完全满足你的应用程序的需求，并让你的应用程序理解框架(php，.net,java)是如何工作的，你就能从硬件上得到更好的东西。
例如，Facebook改变了Linux中的一些内核级别的东西，改变了memcached的工作方式(例如，他们写了一个memcached代理，使用udp而不是tcp)。
另一个例子是Window2008。Win2K8有一个版本，你可以安装运行X应用程序所需的基本操作系统(例如web应用程序，服务器应用程序)。这大大减少了操作系统在运行进程方面的开销，并为您提供了更好的性能。
当然，你应该在第一步就投入更多的硬件……
建议:
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.
很难对这个问题给出一般的答案。这实际上取决于你的问题领域和技术实现。一种与语言无关的通用技术:识别无法消除的代码热点，并手工优化汇编代码。
更多的建议:
Avoid I/O: Any I/O (disk, network, ports, etc.) is always going to be far slower than any code that is performing calculations, so get rid of any I/O that you do not strictly need. Move I/O up-front: Load up all the data you are going to need for a calculation up-front, so that you do not have repeated I/O waits within the core of a critical algorithm (and maybe as a result repeated disk seeks, when loading all the data in one hit may avoid seeking). Delay I/O: Do not write out your results until the calculation is over, store them in a data structure and then dump that out in one go at the end when the hard work is done. Threaded I/O: For those daring enough, combine 'I/O up-front' or 'Delay I/O' with the actual calculation by moving the loading into a parallel thread, so that while you are loading more data you can work on a calculation on the data you already have, or while you calculate the next batch of data you can simultaneously write out the results from the last batch.
