原文链接：https://github.com/sxs2473/go...
本文使用 Creative Commons Attribution-ShareAlike 4.0 International 协议进行授权许可。

总结

保持简单

从最简单的代码开始。

测量！ 分析你的代码来找到瓶颈， 不要猜测 !

如果性能还不错， 收手吧 ！你不需要优化所有的代码，只需要针对影响最大的部分就可以了。

不是程序的每部分都需要高性能

对于大多数关注性能的应用程序，适用80/20规则。80%的时间将花在20%的代码上。

随着应用程序的增长或业务发展，这些性能问题的重点将会变化。

不要留着对性能不重要的复杂代码，如果瓶颈转移到其他地方，就用更简单的实现重写它。

Go 编译器针对简单代码进行了优化

总是写你能写出的最简单的代码，编译器针对简单代码进行了优化。我不说 惯用的 ，因为我不喜欢我们在讨论 Go 时使用这个词。我只说简单，而不是 聪明 的代码。

更短的代码就是更快； Go 不是 C++，不要指望编译器解开复杂的抽象。

更短的代码体积更小；这对 CPU 的缓存很重要。

注意二次方复杂度的操作

If a program is too slow, it must have a loop -- Ken Thompson

大多数程序在少量数据的情况下表现良好。 这是 Pike's 3rd rule 思想背后的精髓。

然而，当数据集很大时，任何接触输入集不止一次的东西，例如，对于集合中的每个元素，对集合中的每个其他元素进行测试，都有可能成为性能方面的大问题。

限制程序各部分之间的通信和协调点，以遵守 Amdahl定律。

性能经验法则

网络/硬盘 io >> 内存分配 >> 函数调用 （ >> 表示远远大于，意味着数量级之间的差距）

如果您的程序主要工作是网络或硬盘访问，那么不要费心去优化内存分配方面的事情。重点关注如何利用缓冲和批处理，以减少等待IO的时间。

如果您的程序是主要工作是分配和管理内存，不要费心去优化函数内联、循环展开等事情。

注意内存分配的使用，尽量避免不必要的分配。

不要为了可靠性而牺牲性能

I can make things very fast if they don't have to be correct. -- Russ Cox

最后，不要为了可靠性而牺牲性能

Readable means reliable -- Rob Pike

性能和可靠性同样重要。

谢谢

有疑问加站长微信联系（非本文作者）