以下是我使用的一些快速而粗糙的优化技术。我认为这是“第一关”优化。

了解时间都花在了什么地方。是文件IO吗?是CPU时间吗?是因为网络吗?是数据库吗?如果IO不是瓶颈，优化IO是没有用的。

了解您的环境了解在哪里进行优化通常取决于开发环境。例如，在VB6中，通过引用传递比通过值传递慢，但是在C和c++中，通过引用传递要快得多。在C语言中，如果返回代码表明失败，尝试一些东西并做一些不同的事情是合理的，而在Dot Net中，捕获异常比尝试前检查有效条件要慢得多。

在频繁查询的数据库字段上构建索引。你几乎总是可以用空间来换取速度。

在要优化的循环内部，我避免了必须进行任何查找。找到循环外的偏移量和/或索引，并重用循环内的数据。

最小化IO尝试以一种减少必须读或写的次数的方式进行设计，特别是在网络连接上

减少抽象代码必须通过的抽象层越多，它就越慢。在关键循环内部，减少抽象(例如，揭示避免额外代码的低级方法)

对于带有用户界面的项目，生成一个新线程来执行较慢的任务使应用程序感觉反应更快，尽管不是。

你通常可以用空间来换取速度。如果有计算或其他密集的操作，看看是否可以在进入关键循环之前预先计算一些信息。

添加这个答案，因为我没有看到它包括在所有其他。

最小化类型和符号之间的隐式转换:

这至少适用于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

我曾见过一些案例，你可以通过减少这样的警告所带来的转化率来获得几个百分点的加速。

在某些情况下，我有一个带有严格警告的头，我保留了这些警告，以防止意外转换，然而这是一种权衡，因为您可能最终会为安静的故意转换添加大量强制转换，这可能会使代码更加混乱，而收益却微乎其微。

不可能有这样的全面陈述，这取决于问题领域。一些可能性:

因为你没有直接指定你的应用程序是100%计算:

搜索阻塞的调用(数据库，网络硬盘，显示更新)，并隔离它们和/或将它们放入线程中。

如果你使用的数据库恰好是Microsoft SQL Server:

研究nolock和rowlock指令。(在这个论坛上有一些讨论。)

如果你的应用是纯粹的计算，你可以看看我关于旋转大图像缓存优化的问题。速度的提高使我大吃一惊。

这是一个长期的尝试，但它可能提供了一个想法，特别是如果您的问题是在成像领域:代码中旋转位图

另一个是尽量避免动态内存分配。一次分配多个结构，一次释放它们。

否则，请确定最紧密的循环，并将它们与一些数据结构一起张贴在这里(无论是伪的还是非的)。

我大半辈子都在这里度过。大致的方法是运行你的分析器并记录它:

Cache misses. Data cache is the #1 source of stalls in most programs. Improve cache hit rate by reorganizing offending data structures to have better locality; pack structures and numerical types down to eliminate wasted bytes (and therefore wasted cache fetches); prefetch data wherever possible to reduce stalls. Load-hit-stores. Compiler assumptions about pointer aliasing, and cases where data is moved between disconnected register sets via memory, can cause a certain pathological behavior that causes the entire CPU pipeline to clear on a load op. Find places where floats, vectors, and ints are being cast to one another and eliminate them. Use __restrict liberally to promise the compiler about aliasing. Microcoded operations. Most processors have some operations that cannot be pipelined, but instead run a tiny subroutine stored in ROM. Examples on the PowerPC are integer multiply, divide, and shift-by-variable-amount. The problem is that the entire pipeline stops dead while this operation is executing. Try to eliminate use of these operations or at least break them down into their constituent pipelined ops so you can get the benefit of superscalar dispatch on whatever the rest of your program is doing. Branch mispredicts. These too empty the pipeline. Find cases where the CPU is spending a lot of time refilling the pipe after a branch, and use branch hinting if available to get it to predict correctly more often. Or better yet, replace branches with conditional-moves wherever possible, especially after floating point operations because their pipe is usually deeper and reading the condition flags after fcmp can cause a stall. Sequential floating-point ops. Make these SIMD.

我还喜欢做一件事:

将编译器设置为输出程序集清单，并查看它为代码中的热点函数发出了什么。所有那些聪明的优化，“一个好的编译器应该能够自动为你做”?实际的编译器可能不会执行这些操作。我见过GCC发出真正的WTF代码。

以下是我使用的一些快速而粗糙的优化技术。我认为这是“第一关”优化。

了解时间都花在了什么地方。是文件IO吗?是CPU时间吗?是因为网络吗?是数据库吗?如果IO不是瓶颈，优化IO是没有用的。

了解您的环境了解在哪里进行优化通常取决于开发环境。例如，在VB6中，通过引用传递比通过值传递慢，但是在C和c++中，通过引用传递要快得多。在C语言中，如果返回代码表明失败，尝试一些东西并做一些不同的事情是合理的，而在Dot Net中，捕获异常比尝试前检查有效条件要慢得多。

在频繁查询的数据库字段上构建索引。你几乎总是可以用空间来换取速度。

在要优化的循环内部，我避免了必须进行任何查找。找到循环外的偏移量和/或索引，并重用循环内的数据。

最小化IO尝试以一种减少必须读或写的次数的方式进行设计，特别是在网络连接上

减少抽象代码必须通过的抽象层越多，它就越慢。在关键循环内部，减少抽象(例如，揭示避免额外代码的低级方法)

对于带有用户界面的项目，生成一个新线程来执行较慢的任务使应用程序感觉反应更快，尽管不是。

你通常可以用空间来换取速度。如果有计算或其他密集的操作，看看是否可以在进入关键循环之前预先计算一些信息。

我想这已经用不同的方式说过了。但是当你在处理一个处理器密集型算法时，你应该以牺牲其他所有东西为代价来简化最内部循环中的所有东西。

That may seem obvious to some, but it's something I try to focus on regardless of the language I'm working with. If you're dealing with nested loops, for example, and you find an opportunity to take some code down a level, you can in some cases drastically speed up your code. As another example, there are the little things to think about like working with integers instead of floating point variables whenever you can, and using multiplication instead of division whenever you can. Again, these are things that should be considered for your most inner loop.

有时，您可能会发现在内循环中对整数执行数学运算的好处，然后将其缩小为随后可以使用的浮点变量。这是一个牺牲一个部分的速度来提高另一个部分的速度的例子，但在某些情况下，这样做是值得的。