Golang 性能分析

极客时间《Go 语言从入门到实践》学习笔记 14，题图来自网络

47 | 性能分析工具

在安装 graphviz 的时候折腾了很久，macOS Big Sur 11.2.3，主要是在折腾

> brew cleanup && brew update> brew upgrade> xcode-select --install> brew install graphviz> brew upgrade graphviz

虽然也写过一些程序，但是正儿八经的性能分析工具却没怎么用过。

另外一个问题出现在 flamegraph.pl，虽然下载了，但是去没有赋予执行权限

> chmod 755 flamegraph.pl

看到火焰图的时候还是挺开心的。

• 文件方式适合短时间批量运行的程序

• HTTP 方式在运行中查看状态

初始化一个 10000 × 10000 的二维数组居然需要 762 MB 的内存，GC 之后更可怕，只有 1.6 MB

48 | 性能调优示例

性能调优还是挺有意思的，如果是在业务系统中，能看到优化前后的对比，很有成就感。两个调优点，一个是使用了更高效的 easyjson 类库，另一个是使用 string.Builder。

找到系统或程序的瓶颈，以及知道如何调优是需要一定的经验积累的。前者可以通过性能分析工具完成，后者可能需要多了解一些 Go 语言的底层实现机制，以及 Go 相关开发生态。

推荐 Dave Cheney 的 High Performance Go Workshop https://dave.cheney.net/high-performance-go-workshop/dotgo-paris.html#overview （我也还没看）

不知道是不是有更好的性能调优工具？不需要每次修改代码然后以命令行的方式运行，另外，最好能够自动比较调优前后的性能数据。我猜 GoLand 也许可以。

49 | 别让性能被锁住

很多程序的性能问题，都和锁有关，数据库或者编程语言的。

Go 语言中有读写锁，互斥的写锁比较容易理解，而互斥的读锁容易造成“误解”。

LockFree 和 LockAccess 在我的笔记本上性能差距大概是 1:30

Concurrent Map 利用 parition 的原理，把一个大的 Map 变成很多小的 Map，这样就可以避免因为一个大的 Map 整个被锁定（锁冲突）的情况

读多写少的时候，使用 sync.map 读写都很频繁的时候使用 Concurrent Map

但是从我本地测试的情况来看，直到读写比 50:1 的时候，sync.Map 在性能上才超过了 Concurrent Map。

按照留言中的线索，读写比例在 10:1 的时候，sync.map 和 concurrent_map 的性能差距大概是 1:2；如果将读写比例设定为 1:1 的时候，性能比上升为 1:5，concurrent_map 的优势更为明显。