在这个网站上已经有很多性能问题了，但是在我看来，几乎所有的问题都是非常具体的，而且相当狭窄。几乎所有人都重复了避免过早优化的建议。
我们假设:
代码已经正常工作了 所选择的算法对于问题的环境已经是最优的 对代码进行了测量，并隔离了有问题的例程 所有优化的尝试也将被衡量，以确保它们不会使事情变得更糟
我在这里寻找的是策略和技巧，在一个关键算法中，当没有其他事情可做，但无论如何都要挤出最后百分之几。
理想情况下，尽量让答案与语言无关，并在适用的情况下指出所建议的策略的任何缺点。
我将添加一个带有我自己最初建议的回复，并期待Stack Overflow社区能想到的任何其他东西。
当前回答
分而治之
如果正在处理的数据集太大，则对其中的大块进行循环。如果代码编写正确，实现应该很容易。如果您有一个单片程序，现在您就更清楚了。
其他回答
内联例程(消除调用/返回和参数推送) 试着用表查找(如果它们更快的话)消除测试/开关 展开循环(Duff的设备)到刚好适合CPU缓存的位置 本地化内存访问，以免耗尽缓存 如果优化器还没有本地化相关的计算 如果优化器还没有这样做，就消除循环不变量
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.
不像之前的答案那么深入或复杂，但下面是: (这些更多是初级/中级水平)
明显:干 向后运行循环，所以总是与0比较，而不是与变量比较 尽可能使用位操作符 将重复的代码分解为模块/函数 缓存对象 局部变量具有轻微的性能优势 尽可能限制字符串操作
更多的建议:
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.
减少可变大小(在嵌入式系统中)
如果您的变量大小大于特定体系结构上的单词大小，则会对代码大小和速度产生重大影响。例如，如果你有一个16位系统，经常使用一个长int变量，然后意识到它永远不能超出范围(−32.768…32.767)考虑将其减少到短int。
从我的个人经验来看，如果一个程序已经准备好或几乎准备好了，但是我们意识到它占用了目标硬件程序内存的110%或120%，那么对变量进行快速归一化通常可以解决这个问题。
到这个时候，优化算法或部分代码本身可能会变得令人沮丧的徒劳:
重新组织整个结构，程序就不再像预期的那样工作，或者至少引入了许多错误。 做一些聪明的技巧:通常你花了很多时间优化一些东西，并发现代码大小没有或很小的减少，因为编译器无论如何都会优化它。
Many people make the mistake of having variables which exactly store the numerical value of a unit they use the variable for: for example, their variable time stores the exact number of milliseconds, even if only time steps of say 50 ms are relevant. Maybe if your variable represented 50 ms for each increment of one, you would be able to fit into a variable smaller or equal to the word size. On an 8 bit system, for example, even a simple addition of two 32-bit variables generates a fair amount of code, especially if you are low on registers, while 8 bit additions are both small and fast.
