这个站点上已经有很多性能问题，但是据我所知，几乎所有问题都是针对特定问题的，而且范围很窄。几乎所有人都会重复建议，以免过早优化。
假设：
我在这里寻找的是策略和技巧，这些方法和技巧可以使关键算法中的最后几个部分都挤到最后几个百分点，而除了它需要做的事情之外，别无其他。
理想情况下，请尝试使答案与语言无关，并在适用时指出建议策略的任何不利方面。
我将添加带有自己的初步建议的回复，并期待Stack Overflow社区可以想到的其他任何内容。
Answers:
好的，您正在将问题定义为似乎没有太多改进空间的地方。根据我的经验，那是相当罕见的。我试图在1993年11月的Dobbs博士的一篇文章中对此进行解释，从一个设计合理，无明显浪费的平凡程序开始，并进行了一系列优化，直到其挂钟时间从48秒减少到到1.1秒，源代码的大小减少了4倍。我的诊断工具是this。更改的顺序是这样的：
发现的第一个问题是使用列表集群（现在称为“迭代器”和“容器类”）占了一半以上的时间。那些被替换为相当简单的代码，使时间减少到20秒。
现在最大的时间接受者是建立更多的清单。以百分比计，它以前没那么大，但是现在是因为消除了更大的问题。我找到了一种加快速度的方法，时间减少到17秒。
现在很难找到明显的罪魁祸首，但是我可以做一些较小的罪魁祸首，而时间缩短到13秒。
现在我似乎撞墙了。这些样本准确地告诉了我它在做什么，但是我似乎找不到任何可以改进的地方。然后，我对程序的基本设计，事务驱动的结构进行了反思，并询问该程序正在执行的所有列表搜索是否实际上都是由问题的要求所强制执行的。
然后我进行了重新设计，在该程序中，实际上是从较小的一组源中（通过预处理器宏）生成了程序代码，并且在该程序中，程序并没有不断地弄清程序员知道是可以预知的。换句话说，不要“解释”要做的事情的顺序，而要“编译”它。
现在，由于它变得如此之快，因此很难进行采样，因此我给它做的工作量是其的10倍，但接下来的时间是基于原始的工作量。
更多的诊断表明，它花时间在队列管理上。内联这些将时间减少到7秒。
现在，我一直在做的诊断打印非常重要。冲洗-4秒钟。
现在，花费最大的时间是调用malloc和free。回收对象-2.6秒。
继续进行示例，我仍然发现并非绝对必要的操作-1.1秒。
总加速因子：43.6
现在没有两个程序是相同的，但是在非玩具软件中，我总是看到这样的进展。首先，您会获得一些简单的东西，然后获得更多的困难，直到收益递减。然后，您获得的见解很可能会导致重新设计，开始新一轮的提速，直到您再次获得递减的收益。现在，这是它可能是有意义的怀疑是否点++i或i++或for(;;)或while(1)更快：题型我看到经常堆栈溢出。
PS也许想知道为什么我不使用探查器。答案是这些“问题”中的几乎每个都是一个函数调用站点，这些站点会精确地采样。直到今天，事件探查器仍几乎不了解这样的想法，即语句和调用指令比整个功能更重要的是定位和更容易修复。
我实际上构建了一个探查器来执行此操作，但是对于与代码正在做的事情真正亲密无间的亲密关系，没有什么可替代的。样本数量很少不是问题，因为发现的所有问题都没有很小到可以轻易遗漏的程度。
添加：jerryjvl请求了一些示例。这是第一个问题。它由少量单独的代码行组成，耗时超过一半：
/* IF ALL TASKS DONE, SEND ITC_ACKOP, AND DELETE OP */
if (ptop->current_task >= ILST_LENGTH(ptop->tasklist){
. . .
/* FOR EACH OPERATION REQUEST */
for ( ptop = ILST_FIRST(oplist); ptop != NULL; ptop = ILST_NEXT(oplist, ptop)){
. . .
/* GET CURRENT TASK */
ptask = ILST_NTH(ptop->tasklist, ptop->current_task)
这些正在使用列表集群ILST（类似于列表类）。它们以通常的方式实现，带有“信息隐藏”，这意味着该类的用户不必关心如何实现它们。编写这些行时（大约800行代码中），并未想到它们可能是“瓶颈”（我讨厌那个词）。它们只是推荐的操作方式。在事后看来，应该避免这些事情很容易，但是以我的经验来看，所有性能问题都是这样。通常，最好避免产生性能问题。最好找到并修复所创建的对象，即使它们“应该避免”（事后看来）。
这是第二个问题，分为两行：
/* ADD TASK TO TASK LIST */
ILST_APPEND(ptop->tasklist, ptask)
. . .
/* ADD TRANSACTION TO TRANSACTION QUEUE */
ILST_APPEND(trnque, ptrn)
这些是通过在项目末尾附加项目而建立的列表。（解决方法是将项目收集到数组中，并一次构建所有列表。）有趣的是，这些语句仅花费（即在调用堆栈上）原始时间的3/48，因此它们不在刚开始时是一个大问题。但是，在消除第一个问题之后，它们花费了3/20的时间，因此成为了“大鱼”。总的来说，就是这样。
我可能会补充说，这个项目是从我帮助过的真实项目中提炼出来的。在该项目中，性能问题更为严重（与提速一样），例如在内部循环中调用数据库访问例程以查看任务是否完成。
参考：原始和重新设计的源代码可以在1993年的www.ddj.com中找到，位于文件9311.zip，文件slug.asc和slug.zip中。
编辑2011/11/26：现在有一个SourceForge项目，其中包含Visual C ++中的源代码以及对其进行调整的详细说明。它仅经历上述场景的前半部分，并且不遵循完全相同的顺序，但是仍然会加快2-3个数量级。
意见建议：
当您无法再提高性能时，请查看是否可以提高感知性能。
您可能无法使自己的fooCalc算法更快，但是通常有一些方法可以使您的应用程序对用户的响应更快。
一些例子：
这些不会使您的程序更快，但是可能会使您的用户对自己的速度感到满意。
我一生的大部分时间都在这个地方。大招是运行您的探查器并进行记录：
__restrict以向编译器承诺有关别名的信息。我还想做一件事：
Examples on the PowerPC ...<-即PowerPC的某些实现。PowerPC是ISA，而不是CPU。
lea。
扔更多的硬件！
更多建议：
避免使用I / O：任何I / O（磁盘，网络，端口等）总是比执行计算的任何代码都要慢得多，因此请摆脱不必要的任何I / O。
提前移动I / O：预先加载计算所需的所有数据，这样就不会在关键算法的核心内重复I / O等待（并且可能会重复执行）磁盘搜索，一次加载所有数据时可以避免搜索）。
延迟I / O：在计算结束之前，不要写出结果，将结果存储在数据结构中，然后在完成艰苦工作后立即一次性转储。
线程I / O：对于那些足够大胆的人，可以通过将加载移到并行线程中，将“ I / O前期”或“延迟I / O”与实际计算结合起来，以便在加载更多数据时可以工作根据已有数据进行计算，或者在计算下一批数据时，可以同时写出上一批数据的结果。
mmap()用于输入，进行适当的madvise()调用并用于aio_write()写入大块输出（=几个MiB）。
由于许多性能问题都涉及数据库问题，因此在调整查询和存储过程时，我将为您提供一些具体的信息。
避免在大多数数据库中使用游标。避免循环。在大多数情况下，数据访问应基于集合，而不是通过记录处理进行记录。当您要一次插入1,000,000条记录时，这包括不重用单个记录存储过程。
切勿使用select *，仅返回您实际需要的字段。如果存在任何联接，则尤其如此，因为联接字段将重复，从而在服务器和网络上造成不必要的负载。
避免使用相关的子查询。使用联接（如果可能，包括联接到派生表）（我知道这对于Microsoft SQL Server是正确的，但是在使用其他后端时请测试建议）。
索引，索引，索引。并更新那些统计信息（如果适用于您的数据库）。
使查询可修改。含义应避免使用索引无法使用的事情，例如在like子句的第一个字符中使用通配符，或者在联接中或在where语句的左侧使用函数。
使用正确的数据类型。与必须先将字符串数据类型转换为日期数据类型然后进行计算相比，对日期字段进行日期数学运算要快得多。
切勿将任何形式的循环带入触发器！
大多数数据库都有一种检查查询执行方式的方法。在Microsoft SQL Server中，这称为执行计划。首先检查那些，看看问题所在。
在确定需要优化的内容时，请考虑查询的运行频率以及运行时间。有时候，通过对每天运行数百万次的查询进行细微调整，可以获得比从每月仅运行一次的long_running查询中消除时间所获得的性能更高的性能。
使用某种事件探查器工具来查找实际发送到数据库或从数据库发送的内容。我记得过去有一次，我们无法弄清楚为什么存储过程很快时页面加载如此缓慢的原因，并通过分析发现网页多次而不是一次查询。
探查器还将帮助您查找谁阻止了谁。由于其他查询的锁定，某些在单独运行时快速执行的查询可能会变得非常慢。
今天，最重要的限制因素是有限的存储带宽。多核只会使情况变得更糟，因为带宽是在多核之间共享的。而且，专用于实现高速缓存的有限芯片区域也分配在内核和线程之间，这使该问题更加恶化。最后，随着内核数量的增加，保持不同缓存一致性所需的芯片间信令也随之增加。这也增加了罚款。
这些是您需要管理的效果。有时是通过对代码进行微管理，但有时是通过仔细考虑和重构。
已经有很多评论提到了缓存友好的代码。至少有两种不同的风格：
第一个问题特别与使数据访问模式更规则有关，从而允许硬件预取器有效地工作。避免动态分配内存，这会分散您的数据对象在内存中的位置。使用线性容器而不是链表，哈希表和树。
第二个问题与改善数据重用性有关。修改算法以处理适合可用缓存的数据子集，并在数据仍在缓存中时尽可能多地重用该数据。
更紧密地打包数据并确保您在热循环中使用高速缓存行中的所有数据，这将有助于避免这些其他影响，并允许在高速缓存中放入更多有用的数据。
尽管我喜欢Mike Dunlavey的答案，但实际上，通过支持示例确实是一个不错的答案，我认为可以这样简单地表达它：
首先找出最耗时的时间，然后了解原因。
时间猪的识别过程可以帮助您了解必须在哪里优化算法。对于我认为已经完全优化的问题，这是唯一能够涵盖所有语言的不可知论答案。还要假设您希望速度不依赖于体系结构。
因此，虽然可以优化算法，但可能无法实现。通过标识，您可以知道哪个部分是哪一部分：算法或实现。因此，最浪费时间的人是您进行审查的主要人选。但是，由于您说要挤出最后的几个百分比，因此您可能还希望检查较小的部分，这些部分起初您没有仔细检查过。
最后，通过性能指标的反复试验，以不同的方式来实现相同的解决方案，或者可能使用不同的算法，可以带来有助于识别时间浪费者和时间节省者的见解。
HPH，行进。
分而治之
如果正在处理的数据集太大，则循环遍历它的大块。如果您正确编写了代码，则实现应该很容易。如果您有一个整体程序，那么现在您会更加了解。
首先，如先前的一些答案中所述，了解影响性能的是内存还是处理器，网络，数据库还是其他东西。取决于...
...如果有记忆，可以找Knuth很久以前写的书之一，它是“计算机编程的艺术”系列之一。很可能是关于排序和搜索的问题-如果我的记忆不对，那么您将不得不找出他在其中谈论如何处理慢速磁带数据存储的问题。轻轻地将他的记忆/录音带对分别转换为缓存/主内存对（或L1 / L2缓存对）。研究他描述的所有技巧-如果您找不到解决问题的方法，请雇用专业的计算机科学家进行专业研究。如果您的存储问题是偶然的FFT（做基数为2的蝴蝶时，高速缓存未命中位反转索引），那么就不要聘请科学家-而是手动逐个手动优化传递，直到 挤到最后百分之几吧？如果确实很少，那么您很可能会赢。
...如果是处理器-切换到汇编语言。研究处理器规格- 需要滴答，VLIW，SIMD。函数调用很可能是可替换的tick子。学习循环转换-管道，展开。乘法和除法可以用移位来替换/内插（乘以小整数可以用加法来替换）。尝试使用较短数据的技巧-如果幸运的话，一条64位的指令可能会被32位的2位甚至16位的4位或8位的8位替换。也尽量不再数据-例如，在特定处理器上，您的浮点计算可能比双精度计算慢。如果您有三角函数，请使用预先计算的表格进行处理；还请记住，如果精度损失在允许的范围内，则较小值的正弦值可能会替换为该值。
...如果是网络-考虑压缩您通过的数据。用二进制替换XML传输。研究方案。如果可以某种方式处理数据丢失，请尝试使用UDP而不是TCP。
...如果是数据库，那么，请转到任何数据库论坛并寻求建议。内存中的数据网格，优化查询计划等等等。
HTH :)
我认为这已经以不同的方式表达了。但是，当您要处理处理器密集型算法时，应该简化最内部循环中的所有内容，而要牺牲其他所有内容。
对于某些人来说，这似乎很明显，但是无论我使用哪种语言，我都试图专注于此。例如，如果您正在处理嵌套循环，并且发现将某个代码降级的机会，则在某些情况下可以大大加快代码的速度。再举一个例子，您可以考虑一些小事情，例如，尽可能使用整数而不是浮点变量，并尽可能使用乘法而不是除法。同样，这些是您最内在的循环应该考虑的事情。
有时，您可能会发现在内部循环内的整数上执行数学运算，然后将其缩放到随后可以使用的浮点变量的好处。这是牺牲一个部分的速度来提高另一个部分的速度的示例，但是在某些情况下，回报是值得的。
我花了一些时间来优化在低带宽和长延迟网络（例如，卫星，远程，离岸）上运行的客户端/服务器业务系统，并且能够通过相当可重复的过程实现一些显着的性能改进。
措施：首先了解网络的基础容量和拓扑。与业务中的相关网络人员交谈，并使用ping和traceroute之类的基本工具在典型的运营周期内（至少）建立每个客户端位置的网络延迟。接下来，对显示问题症状的特定最终用户功能进行准确的时间测量。记录所有这些测量值及其位置，日期和时间。考虑将最终用户的“网络性能测试”功能内置到您的客户端应用程序中，从而使您的高级用户可以参与改进过程；当您与表现不佳的系统而沮丧的用户打交道时，像这样授权他们可能会对心理产生巨大影响。
分析：使用所有可用的日志记录方法来准确确定在执行受影响的操作期间正在发送和接收的数据。理想情况下，您的应用程序可以捕获客户端和服务器发送和接收的数据。如果这些还包括时间戳，那就更好了。如果没有足够的日志记录（例如，封闭的系统或无法将修改部署到生产环境中），请使用网络嗅探器并确保您真正了解网络级别的情况。
缓存：查找重复传输静态或不经常更改的数据的情况，并考虑适当的缓存策略。典型示例包括“选择列表”值或其他“参考实体”，这在某些业务应用程序中可能会非常大。在许多情况下，用户可以接受他们必须重新启动或刷新应用程序以更新不经常更新的数据的情况，尤其是如果它可以从显示常用用户界面元素中节省大量时间时，尤其如此。确保您了解已经部署的缓存元素的真实行为-许多常见的缓存方法（例如HTTP ETag）仍然需要网络往返以确保一致性，并且在网络延迟昂贵的情况下，您可以完全避免这种情况一种不同的缓存方法。
并行：寻找逻辑上不需要严格按顺序发出的顺序事务，并重新设计系统以并行发出它们。我处理了一种情况，端到端请求的固有网络延迟为〜2s，这对单笔交易而言不是问题，但是在用户重新获得对客户端应用程序的控制之前，需要6次连续2s往返，这成为挫败感的巨大根源。发现这些事务实际上是独立的，从而允许它们并行执行，从而将最终用户的延迟减少到非常接近单次往返的成本。
合并：必须依次执行顺序请求的地方，寻找将它们组合为一个更全面的请求的机会。典型示例包括创建新实体，然后是将这些实体与其他现有实体相关联的请求。
压缩：寻找机会来利用有效载荷的压缩，方法是用二进制形式替换文本形式，或者使用实际的压缩技术。许多现代（即十年之内）的技术堆栈几乎都透明地支持此功能，因此请确保已对其进行配置。我经常对压缩的巨大影响感到惊讶，因为压缩的影响似乎从根本上是延迟而不是带宽，这是事实发现的，它使事务适合单个数据包，或者避免了数据包丢失，因此具有超大容量对性能的影响。
重复：回到开始，并在适当的改进下重新衡量您的操作（在相同的位置和时间），记录并报告结果。与所有优化一样，某些问题可能已经解决，而其他问题则暴露无遗。
在上述步骤中，我着重于与应用程序相关的优化过程，但是当然，您必须确保以最有效的方式配置基础网络本身，以支持您的应用程序。与企业中的网络专家合作，确定他们是否能够应用容量改进，QoS，网络压缩或其他技术来解决问题。通常，他们不会理解您的应用程序的需求，因此，您有能力（在“分析”步骤之后）与他们进行讨论，并为您要让他们招致的任何费用提供业务案例，这一点很重要。我遇到过以下情况：错误的网络配置导致应用程序数据通过慢速卫星链路而不是陆上链路传输，仅仅是因为它使用了网络专家不为人所知的TCP端口；显然，纠正此类问题可能会对性能产生巨大影响，根本不需要更改软件代码或配置。
深度或复杂性不及先前的答案，但有：（这些是初学者/中级）
如果可以选择更好的硬件，那么绝对可以。除此以外
这是我使用的一些快速而肮脏的优化技术。我认为这是“首过”优化。
了解花在哪里的时间确切地了解花费的时间。是文件IO吗？是CPU时间吗？是网络吗？是数据库吗？如果这不是瓶颈，则无法优化IO。
知道您的环境 知道在哪里进行优化通常取决于开发环境。例如，在VB6中，按引用传递比按值传递要慢，但是在C和C ++中，按引用传递要快得多。在C语言中，如果返回码指示失败，则尝试某些操作并做一些不同的事情是合理的；而在Dot Net中，捕获异常比在尝试之前检查有效条件要慢得多。
指数构建上频繁查询数据库字段的索引。您几乎总是可以以空间换取速度。
避免查找 在要优化的循环内部，我避免进行任何查找。在循环外部找到偏移量和/或索引，然后在内部重用数据。
最大限度地减少IO尝试设计的方式，从而减少您必须通过网络连接进行读取或写入的次数
减少抽象代码必须处理的抽象层越多，速度越慢。在关键循环内，减少抽象（例如，揭示避免额外代码的低级方法）
带有用户界面的项目的Spawn Threads产生了一个新的线程来执行较慢的任务，这使应用程序感到响应更快，尽管没有。
预处理通常，您可以以空间换取速度。如果有计算或其他繁琐的操作，请查看是否可以在进入关键循环之前预先计算一些信息。
添加此答案，因为我没有看到它包含在所有其他答案中。
这至少适用于C / C ++，即使您已经认为自己无需转换-有时也可以测试在需要性能的函数周围添加编译器警告，特别是注意循环内的转换。
特殊的GCC：您可以通过在代码周围添加一些详细的注释来进行测试，
#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
我见过一些情况，通过减少此类警告引起的转换，您可以提高百分之几的速度。
在某些情况下，我会包含一个带有严格警告的标头，以防止发生意外转换，但这是一种折衷方案，因为您可能最终会向安静的有意转换添加大量强制转换，这只会使代码更加混乱，从而使代码最少收获。
调整操作系统和框架。
听起来可能有些大材小用，但您应该这样想：操作系统和框架旨在完成许多事情。您的应用程序仅执行非常具体的事情。如果您可以让OS完全满足您的应用程序的需求，并使您的应用程序了解框架（php，.net，java）的工作方式，那么您的硬件就会变得更好。
例如，Facebook改变了Linux中的一些内核级别的东西，改变了memcached的工作方式（例如，他们编写了memcached代理，并使用udp代替tcp）。
另一个例子是Window2008。Win2K8有一个版本，您可以仅安装运行X应用程序所需的基本操作系统（例如Web应用程序，服务器应用程序）。这样可以减少操作系统在运行进程上的大量开销，并为您提供更好的性能。
当然，作为第一步，您应该始终添加更多硬件。