在这个网站上已经有很多性能问题了，但是在我看来，几乎所有的问题都是非常具体的，而且相当狭窄。几乎所有人都重复了避免过早优化的建议。
我们假设:
代码已经正常工作了 所选择的算法对于问题的环境已经是最优的 对代码进行了测量，并隔离了有问题的例程 所有优化的尝试也将被衡量，以确保它们不会使事情变得更糟
我在这里寻找的是策略和技巧，在一个关键算法中，当没有其他事情可做，但无论如何都要挤出最后百分之几。
理想情况下，尽量让答案与语言无关，并在适用的情况下指出所建议的策略的任何缺点。
我将添加一个带有我自己最初建议的回复，并期待Stack Overflow社区能想到的任何其他东西。
当前回答
由于许多性能问题都涉及数据库问题，因此在调优查询和存储过程时，我将介绍一些需要注意的具体问题。
避免在大多数数据库中使用游标。也要避免循环。大多数时候，数据访问应该基于设置，而不是逐条记录处理。这包括当您希望一次插入1,000,000条记录时，不要重用单个记录存储过程。
不要使用select *，只返回实际需要的字段。如果存在任何连接，则尤其如此，因为连接字段将重复，从而在服务器和网络上造成不必要的负载。
避免使用相关的子查询。使用连接(尽可能包括到派生表的连接)(我知道这对于Microsoft SQL Server是正确的，但是在使用不同的后端时测试建议)。
索引，索引，索引。如果适用于您的数据库，请更新这些统计数据。
使查询sargable。这意味着避免一些不可能使用索引的事情，例如在like子句的第一个字符中使用通配符，或在join中的函数中使用通配符，或作为where语句的左侧部分。
使用正确的数据类型。在日期字段上进行日期计算要比尝试将字符串数据类型转换为日期数据类型然后进行计算快得多。
永远不要在触发器中放入任何形式的循环!
大多数数据库都有一种方法来检查如何执行查询。在Microsoft SQL Server中，这被称为执行计划。先检查一下，看看问题出在哪里。
在确定需要优化的内容时，考虑查询运行的频率以及运行所需的时间。有时，对一个每天运行数百万次的查询稍作调整，可以获得比删除一个月只运行一次的long_running查询更多的性能。
使用某种分析器工具来找出发送到数据库和从数据库发送的内容。我记得过去有一次，我们不知道为什么页面加载这么慢，而存储过程却很快，并通过分析发现网页多次而不是一次地请求查询。
剖析器还将帮助您找到谁在阻止谁。一些单独运行时执行很快的查询可能会因为来自其他查询的锁而变得非常慢。
其他回答
您可能应该考虑“谷歌视角”，即确定您的应用程序如何在很大程度上实现并行和并发，这也不可避免地意味着在某种程度上考虑将您的应用程序分布在不同的机器和网络上，这样它就可以理想地与您投入的硬件几乎线性扩展。
另一方面，谷歌人员也以投入大量人力和资源来解决他们正在使用的项目、工具和基础设施中的一些问题而闻名，例如，通过拥有一个专门的工程师团队来破解gcc内部，以便为Google典型的用例场景做好准备，从而对gcc进行整个程序优化。
类似地，分析应用程序不再仅仅意味着分析程序代码，还包括它周围的所有系统和基础设施(想想网络、交换机、服务器、RAID阵列)，以便从系统的角度识别冗余和优化潜力。
你知道吗，一根CAT6电缆能够比缺省的Cat5e UTP电缆更好地屏蔽外部干扰10倍?
对于任何非离线项目，尽管拥有最好的软件和硬件，但如果你的throughoutput很弱，那么这条细线就会挤压数据并给你带来延迟，尽管只有几毫秒……
此外，CAT6电缆的最大吞吐量更高，因为您实际上更有可能收到铜芯电缆，而不是CCA，铜芯包覆铝，这通常出现在所有标准CAT5e电缆中。
如果您面临丢包，丢包，那么提高24/7操作的吞吐量可靠性可以使您所寻找的不同。
对于那些追求家庭/办公室连接可靠性的人来说(并且愿意对今年的快餐店说不，在年底你可以在那里)，以知名品牌的CAT7电缆的形式为自己提供LAN连接的顶峰。
虽然我喜欢Mike Dunlavey的回答，但事实上这是一个很好的答案，并且有支持的例子，我认为它可以简单地表达出来:
首先找出哪些事情最耗费时间，并了解原因。
它是时间消耗的识别过程，可以帮助您了解必须在哪里改进算法。这是我能找到的唯一一个全面的语言不可知论答案，这个问题已经被认为是完全优化的。同时假设您希望在追求速度的过程中独立于体系结构。
因此，虽然算法可能被优化了，但它的实现可能没有。标识可以让您知道哪个部分是哪个部分:算法或实现。所以，占用时间最多的就是你审查的首选对象。但是既然你说你想把最后的%挤出来，你可能还想检查一下较小的部分，那些你一开始没有仔细检查过的部分。
最后，对实现相同解决方案的不同方法的性能数据进行一些尝试和错误，或者可能的不同算法，可以带来有助于识别浪费时间和节省时间的见解。
HPH, asoudmove。
最后几个%是一个非常CPU和应用程序依赖的东西....
缓存架构不同，有些芯片有片上内存 你可以直接映射，ARM的(有时)有一个矢量 单位，SH4是一个有用的矩阵操作码。有GPU吗 也许一个着色器是可行的。TMS320非常 对循环中的分支敏感(因此分离循环和 如果可能的话，将条件移到室外)。
名单在....上但这类事情真的是 最后的手段……
编译x86，并运行Valgrind/Cachegrind对代码 进行适当的性能分析。或者德州仪器的 CCStudio有一个贴心的侧写器。然后你就知道在哪里了 关注……
当你不能再提高表现时，看看你是否可以提高感知的表现。
您可能无法使您的fooCalc算法更快，但通常有一些方法可以使您的应用程序对用户的响应更快。
举几个例子:
预测用户将要做什么 请求并开始着手这项工作 在那之前 将结果显示为 它们是进来的，而不是同时出现的 在最后 精确的进度计
这些不会让你的程序更快，但可能会让你的用户对你的速度更满意。
