编写和优化Go代码

本文档概述了编写高性能Go代码的最佳实践。

虽然有些讨论会提高单个服务的速度(通过缓存等),但设计高性能的分布式系统已经超出了这项工作的范围。在监控和分布式系统设计方面已经有很好的文章,它包含了一套完全不同的研究和设计权衡理论。

所有内容将根据CC-BY-SA进行许可。

本书分为不同的部分:

  1. 1) 编写高性能软件的基本技巧
  2. * CS 101-level的东西
  3. 2) 编写快速软件的技巧
  4. * 关于如何从Go获得最佳效果的Go-specific章节
  5. 3) 编写*真正*快速软件的高级技巧
  6. * 当你优化的代码不够快时

我们可以总结这三个部分:

  • “合理的”
  • “慎重的”
  • “危险的”

何时何地做优化

我先把这个放在第一位,是因为这真的是最重要的一步。你曾经也应该这样做吗?

每个优化都有成本。通常,这个成本是用代码复杂度或认知负载来表示的 - 优化后的代码很少比未优化的版本简单。

但另一方面,我将称之为“优化经济学”。作为程序员,你的时间是宝贵的。你可以为你的项目工作的机会成本,哪些错误需要修复,以及需要添加哪些功能。优化的工作是很有趣的,但并不总是正确的选择。性能是一项功能,但代价和正确性也是如此。

选择最重要的工作。有时它不是一个实际的CPU优化,而是一个用户体验。就像添加进度条一样简单,或者通过在渲染页面后在后台执行计算来提高页面的响应速度。

有时这是显而易见的:在三小时内完成的报告在一小时完成可能不太有用。

仅仅因为容易优化并不意味着它是值得优化的。忽略low-hang的效果是一种有效的发展战略。

把这看作是优化你的时间。

选择要优化的内容以及何时优化,你可以在“软件质量”和“开发速度”之间移动滑块。

人们无意识地重复说名言——“过早的优化是万恶之源”,但他们错过了它的主要内容。

“程序员浪费了大量的时间来思考或者担心程序中非关键部分的速度,而这些效率的尝试实际上在考虑调试和维护时会产生很大的负面影响。我们应该忘记为了小的性能使用的97%的时间:过早的优化是万恶之源,但我们不应该在这个关键的3%中放弃我们的优化机会。“ - Knuth

附:https : //www.youtube.com/watch?time_continue=429&v=RT46MpK39rQ

  • 不要忽视简单的优化
  • 更多的算法和数据结构知识使得更多的优化变得“容易”或“明显”

“你应该优化吗?”是的,但是只有当问题很重要时,程序真的太慢了​​,并且能够在保证正确性,稳健性和清晰度的同时变得更快。“ - 编程实践,Kernighan and Pike

BitFunnel性能评估 有一些数字可以使这种权衡更加明确。想象一下假设搜索引擎需要跨越多个数据中心的30,000台机器,这些机器每年的成本约为1,000美元。如果你可以将软件的速度提高一倍,这可以为公司节省每年1500万美元。即使只有一个开发人员花费整整一年时间才能将性能提高也只会付出1%的代价。

在绝大多数情况下,程序的大小和速度不是问题。最简单的优化不必这样做。第二个最简单的优化就是购买更快的硬件。

如果你决定要改变你的程序,请继续阅读。

整理来源(书栈小编注)

https://github.com/dgryski/go-perfbook