一般性建议

本书前面的章节讨论了 Rust 特定的技术。本节简要概述了一些一般性能原则。

只要避免明显的陷阱（例如，使用非发布版本），Rust 代码通常是快速的且使用内存少的。特别是如果你习惯于动态类型语言如 Python 和 Ruby，或者带有垃圾回收器的静态类型语言如 Java 和 C#。

优化后的代码通常比未优化的代码更复杂，编写起来需要更多的工作。因此，只有值得优化的热点代码才值得优化。

最大的性能改进通常来自于对算法或数据结构的更改，而不是低级优化。 示例 1, 示例 2。

编写能够很好地与现代硬件配合的代码并不总是容易的，但值得努力。例如，尽量减少缓存未命中和分支预测错误。

大多数优化都会带来小幅度的加速。虽然单个小幅度的加速不会被注意到，但如果你能做足够多的话，它们的确会累加起来。

不同的性能分析工具有不同的优势。最好使用多个。

当性能分析表明某个函数很热时，通常有两种常见的方法可以加速：(a) 加速函数本身，和/或者 (b) 尽量减少对它的调用。

消除愚蠢的减速往往比引入聪明的加速更容易。

除非必要，避免计算。延迟/按需计算通常是有利的。 示例 1, 示例 2。

复杂的一般情况通常可以通过乐观地检查更简单的常见特殊情况来避免。 示例 1, 示例 2, 示例 3。 特别是，在小尺寸占主导地位时，特别处理包含 0、1 或 2 个元素的集合通常是有效的。 示例 1, 示例 2, 示例 3, 示例 4。

类似地，当处理重复数据时，通常可以使用简单的数据压缩形式，通过使用常见值的紧凑表示，然后对于不寻常的值，采用次要表作为回退。 示例 1, 示例 2, 示例 3。

当代码涉及多个情况时，测量各种情况的频率，并首先处理最常见的情况。

当处理具有高局部性的查找时，将一个小型缓存放在数据结构前面可能是一个好主意。

优化后的代码通常具有非显而易见的结构，这意味着解释性注释是有价值的，特别是那些引用了性能分析测量的注释。像“99% 的情况下，这个向量有 0 或 1 个元素，所以首先处理这些情况”的注释可能会很有启发性。