在这个网站上已经有很多性能问题了，但是在我看来，几乎所有的问题都是非常具体的，而且相当狭窄。几乎所有人都重复了避免过早优化的建议。
我们假设:
代码已经正常工作了 所选择的算法对于问题的环境已经是最优的 对代码进行了测量，并隔离了有问题的例程 所有优化的尝试也将被衡量，以确保它们不会使事情变得更糟
我在这里寻找的是策略和技巧，在一个关键算法中，当没有其他事情可做，但无论如何都要挤出最后百分之几。
理想情况下，尽量让答案与语言无关，并在适用的情况下指出所建议的策略的任何缺点。
我将添加一个带有我自己最初建议的回复，并期待Stack Overflow社区能想到的任何其他东西。
当前回答
如果更好的硬件是一个选择，那么一定要去做。否则
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?
其他回答
如果更好的硬件是一个选择，那么一定要去做。否则
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?
不像之前的答案那么深入或复杂，但下面是: (这些更多是初级/中级水平)
明显:干 向后运行循环，所以总是与0比较，而不是与变量比较 尽可能使用位操作符 将重复的代码分解为模块/函数 缓存对象 局部变量具有轻微的性能优势 尽可能限制字符串操作
如果你有很多高度并行的浮点运算——尤其是单精度运算——尝试使用OpenCL或(对于NVidia芯片)CUDA将其卸载到图形处理器上(如果有的话)。gpu在着色器中拥有强大的浮点计算能力，这比CPU要大得多。
添加这个答案，因为我没有看到它包括在所有其他。
最小化类型和符号之间的隐式转换:
这至少适用于C/ c++，即使你已经认为你已经摆脱了转换——有时测试在需要性能的函数周围添加编译器警告是很好的，特别是注意循环中的转换。
特定于GCC:您可以通过在代码周围添加一些冗长的pragmas来测试这一点，
#ifdef __GNUC__
# pragma GCC diagnostic push
# pragma GCC diagnostic error "-Wsign-conversion"
# pragma GCC diagnostic error "-Wdouble-promotion"
# pragma GCC diagnostic error "-Wsign-compare"
# pragma GCC diagnostic error "-Wconversion"
#endif
/* your code */
#ifdef __GNUC__
# pragma GCC diagnostic pop
#endif
我曾见过一些案例，你可以通过减少这样的警告所带来的转化率来获得几个百分点的加速。
在某些情况下，我有一个带有严格警告的头，我保留了这些警告，以防止意外转换，然而这是一种权衡，因为您可能最终会为安静的故意转换添加大量强制转换，这可能会使代码更加混乱，而收益却微乎其微。
您可能应该考虑“谷歌视角”，即确定您的应用程序如何在很大程度上实现并行和并发，这也不可避免地意味着在某种程度上考虑将您的应用程序分布在不同的机器和网络上，这样它就可以理想地与您投入的硬件几乎线性扩展。
另一方面，谷歌人员也以投入大量人力和资源来解决他们正在使用的项目、工具和基础设施中的一些问题而闻名，例如，通过拥有一个专门的工程师团队来破解gcc内部，以便为Google典型的用例场景做好准备，从而对gcc进行整个程序优化。
类似地，分析应用程序不再仅仅意味着分析程序代码，还包括它周围的所有系统和基础设施(想想网络、交换机、服务器、RAID阵列)，以便从系统的角度识别冗余和优化潜力。
