在这个网站上已经有很多性能问题了，但是在我看来，几乎所有的问题都是非常具体的，而且相当狭窄。几乎所有人都重复了避免过早优化的建议。
我们假设:
代码已经正常工作了 所选择的算法对于问题的环境已经是最优的 对代码进行了测量，并隔离了有问题的例程 所有优化的尝试也将被衡量，以确保它们不会使事情变得更糟
我在这里寻找的是策略和技巧，在一个关键算法中，当没有其他事情可做，但无论如何都要挤出最后百分之几。
理想情况下，尽量让答案与语言无关，并在适用的情况下指出所建议的策略的任何缺点。
我将添加一个带有我自己最初建议的回复，并期待Stack Overflow社区能想到的任何其他东西。
当前回答
有时改变数据的布局会有所帮助。在C语言中，可以从数组或结构切换到数组结构，反之亦然。
其他回答
如果更好的硬件是一个选择，那么一定要去做。否则
Check you are using the best compiler and linker options. If hotspot routine in different library to frequent caller, consider moving or cloning it to the callers module. Eliminates some of the call overhead and may improve cache hits (cf how AIX links strcpy() statically into separately linked shared objects). This could of course decrease cache hits also, which is why one measure. See if there is any possibility of using a specialized version of the hotspot routine. Downside is more than one version to maintain. Look at the assembler. If you think it could be better, consider why the compiler did not figure this out, and how you could help the compiler. Consider: are you really using the best algorithm? Is it the best algorithm for your input size?
不可能有这样的全面陈述，这取决于问题领域。一些可能性:
因为你没有直接指定你的应用程序是100%计算:
搜索阻塞的调用(数据库，网络硬盘，显示更新)，并隔离它们和/或将它们放入线程中。
如果你使用的数据库恰好是Microsoft SQL Server:
研究nolock和rowlock指令。(在这个论坛上有一些讨论。)
如果你的应用是纯粹的计算，你可以看看我关于旋转大图像缓存优化的问题。速度的提高使我大吃一惊。
这是一个长期的尝试，但它可能提供了一个想法，特别是如果您的问题是在成像领域:代码中旋转位图
另一个是尽量避免动态内存分配。一次分配多个结构，一次释放它们。
否则，请确定最紧密的循环，并将它们与一些数据结构一起张贴在这里(无论是伪的还是非的)。
更多的建议:
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.
不像之前的答案那么深入或复杂，但下面是: (这些更多是初级/中级水平)
明显:干 向后运行循环，所以总是与0比较，而不是与变量比较 尽可能使用位操作符 将重复的代码分解为模块/函数 缓存对象 局部变量具有轻微的性能优势 尽可能限制字符串操作
不好说。这取决于代码的样子。如果我们可以假设代码已经存在，那么我们可以简单地查看它并从中找出如何优化它。
更好的缓存位置，循环展开，尽量消除长依赖链，以获得更好的指令级并行性。尽可能选择有条件的移动而不是分支。尽可能利用SIMD指令。
理解你的代码在做什么，理解它运行在什么硬件上。然后，决定需要做什么来提高代码的性能就变得相当简单了。这是我能想到的唯一一个真正具有普遍性的建议。
好吧，还有“在SO上显示代码，并为特定的代码段寻求优化建议”。
