在这个网站上已经有很多性能问题了，但是在我看来，几乎所有的问题都是非常具体的，而且相当狭窄。几乎所有人都重复了避免过早优化的建议。
我们假设:
代码已经正常工作了 所选择的算法对于问题的环境已经是最优的 对代码进行了测量，并隔离了有问题的例程 所有优化的尝试也将被衡量，以确保它们不会使事情变得更糟
我在这里寻找的是策略和技巧，在一个关键算法中，当没有其他事情可做，但无论如何都要挤出最后百分之几。
理想情况下，尽量让答案与语言无关，并在适用的情况下指出所建议的策略的任何缺点。
我将添加一个带有我自己最初建议的回复，并期待Stack Overflow社区能想到的任何其他东西。
当前回答
由于许多性能问题都涉及数据库问题，因此在调优查询和存储过程时，我将介绍一些需要注意的具体问题。
避免在大多数数据库中使用游标。也要避免循环。大多数时候，数据访问应该基于设置，而不是逐条记录处理。这包括当您希望一次插入1,000,000条记录时，不要重用单个记录存储过程。
不要使用select *，只返回实际需要的字段。如果存在任何连接，则尤其如此，因为连接字段将重复，从而在服务器和网络上造成不必要的负载。
避免使用相关的子查询。使用连接(尽可能包括到派生表的连接)(我知道这对于Microsoft SQL Server是正确的，但是在使用不同的后端时测试建议)。
索引，索引，索引。如果适用于您的数据库，请更新这些统计数据。
使查询sargable。这意味着避免一些不可能使用索引的事情，例如在like子句的第一个字符中使用通配符，或在join中的函数中使用通配符，或作为where语句的左侧部分。
使用正确的数据类型。在日期字段上进行日期计算要比尝试将字符串数据类型转换为日期数据类型然后进行计算快得多。
永远不要在触发器中放入任何形式的循环!
大多数数据库都有一种方法来检查如何执行查询。在Microsoft SQL Server中，这被称为执行计划。先检查一下，看看问题出在哪里。
在确定需要优化的内容时，考虑查询运行的频率以及运行所需的时间。有时，对一个每天运行数百万次的查询稍作调整，可以获得比删除一个月只运行一次的long_running查询更多的性能。
使用某种分析器工具来找出发送到数据库和从数据库发送的内容。我记得过去有一次，我们不知道为什么页面加载这么慢，而存储过程却很快，并通过分析发现网页多次而不是一次地请求查询。
剖析器还将帮助您找到谁在阻止谁。一些单独运行时执行很快的查询可能会因为来自其他查询的锁而变得非常慢。
其他回答
内联例程(消除调用/返回和参数推送) 试着用表查找(如果它们更快的话)消除测试/开关 展开循环(Duff的设备)到刚好适合CPU缓存的位置 本地化内存访问，以免耗尽缓存 如果优化器还没有本地化相关的计算 如果优化器还没有这样做，就消除循环不变量
当你不能再提高表现时，看看你是否可以提高感知的表现。
您可能无法使您的fooCalc算法更快，但通常有一些方法可以使您的应用程序对用户的响应更快。
举几个例子:
预测用户将要做什么 请求并开始着手这项工作 在那之前 将结果显示为 它们是进来的，而不是同时出现的 在最后 精确的进度计
这些不会让你的程序更快，但可能会让你的用户对你的速度更满意。
以下是我使用的一些快速而粗糙的优化技术。我认为这是“第一关”优化。
了解时间都花在了什么地方。是文件IO吗?是CPU时间吗?是因为网络吗?是数据库吗?如果IO不是瓶颈，优化IO是没有用的。
了解您的环境了解在哪里进行优化通常取决于开发环境。例如，在VB6中，通过引用传递比通过值传递慢，但是在C和c++中，通过引用传递要快得多。在C语言中，如果返回代码表明失败，尝试一些东西并做一些不同的事情是合理的，而在Dot Net中，捕获异常比尝试前检查有效条件要慢得多。
在频繁查询的数据库字段上构建索引。你几乎总是可以用空间来换取速度。
在要优化的循环内部，我避免了必须进行任何查找。找到循环外的偏移量和/或索引，并重用循环内的数据。
最小化IO尝试以一种减少必须读或写的次数的方式进行设计，特别是在网络连接上
减少抽象代码必须通过的抽象层越多，它就越慢。在关键循环内部，减少抽象(例如，揭示避免额外代码的低级方法)
对于带有用户界面的项目，生成一个新线程来执行较慢的任务使应用程序感觉反应更快，尽管不是。
你通常可以用空间来换取速度。如果有计算或其他密集的操作，看看是否可以在进入关键循环之前预先计算一些信息。
如果你有很多高度并行的浮点运算——尤其是单精度运算——尝试使用OpenCL或(对于NVidia芯片)CUDA将其卸载到图形处理器上(如果有的话)。gpu在着色器中拥有强大的浮点计算能力，这比CPU要大得多。
很难对这个问题给出一般的答案。这实际上取决于你的问题领域和技术实现。一种与语言无关的通用技术:识别无法消除的代码热点，并手工优化汇编代码。
