欢迎入坑我的新项目： Go 语言高性能编程

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

The Go Programming Language

› http://golang.org/

› Go Playground

Go Projects

› Revel Web Framework

这是一个创建于 1476 天前的主题，其中的信息可能已经有所发展或是发生改变。

在实现 7days-golang 这个项目过程中，接触到了很多开源项目的源码，里面有很多优雅的实现，结合最近工作中的一些经历，启动了「 Go 语言高性能编程」这个开源电子书项目。Go 语言优秀的电子书其实蛮多的，比如 Go 语言原本，Go 语言实现与设计等，可能对大部分童鞋来说过于深奥了。「 Go 语言高性能编程」这个项目聚焦于编程实践，同时会有少量的原理分析，比较适合希望无痛进阶的初学者~

一个月利用碎片时间写了十篇文章，还顺便改造了下我的 hexo 博客模板，融合了 gitbook 的排版方式。

感兴趣的童鞋可以关注一波，这个项目也是一起兴起，比较肝，提交时间基本在凌晨了。七天用 Go 从零实现这个项目也会继续维护的，不过这个项目特别需要整块的时间，最近整块时间实在太少，新坑一直没填上。

项目地址：high-performance-go

性能

切片

项目

编程

84 条回复 • 2020-12-15 12:42:44 +08:00

kevinwan

2020-12-13 19:04:24 +08:00 via iPhone

支持

gzdaijie

2020-12-13 19:05:24 +08:00

@kevinwan 活捉大佬一枚，关注了~

kevinwan

2020-12-13 19:14:31 +08:00

@gzdaijie 共建 Go 生态🤝

youngce

2020-12-13 19:42:02 +08:00

支持！！！！看过博主的 geecache 系列，太棒了

oxromantic

2020-12-13 20:04:41 +08:00

减少体积那个。。。upx 就不要拿出来提了吧，另外都用 go 了，也不会在乎细微的体积差别了

gzdaijie

2020-12-13 20:10:42 +08:00 via Android

@oxromantic 因为在公司会做一些插件小工具，10MB 压缩到 3MB，7MB 的差异对我来说，是至关重要的，不知道有啥更好的压缩体积的方法？

gzdaijie

2020-12-13 20:11:26 +08:00 via Android

@youngce 笔芯～

Mitt

2020-12-13 20:22:35 +08:00

@gzdaijie #6 要是 windows 这种用户类的软件可能 upx 有点用，不然可能会起反效果，upx 的解压过程在内存里，没必要为了省那点硬盘浪费内存

wzw

2020-12-13 20:27:25 +08:00 via iPhone

每一篇，都值得看，谢谢

gzdaijie

2020-12-13 20:32:34 +08:00 via Android

@Mitt 感谢建议，我可以再去探索下各种场景的实践。我自己服务器部署的服务是不会用的，但是一些插件的场景，考虑到设备空间，或是 hook 的场景，套在常用命令前执行，体积对性能上是有影响的。

wzw

2020-12-13 21:11:53 +08:00 via iPhone

减少编译体积，会影响性能吗

SjwNo1

2020-12-13 21:14:26 +08:00

收藏了慢慢看

cabing

2020-12-13 21:22:52 +08:00

棒棒哒，建议可以完善下 go 的并发工具。参考 juc

mouzhiyang

2020-12-13 21:25:30 +08:00

支持

CrazyBoyFeng

2020-12-13 21:30:08 +08:00

减少体积这条现在意义不大，-s 和-w 参数能省的空间并不多。比较有效的就是 upx，但在启动时解压缩会多消耗 cpu 和内存。
不知道 golang 官方有没有出动态链接编译的计划。搭配发行 runtime environment 或者发行模块化动态链接库。做到一库多用。只有这样才能节省硬盘和内存。不过如此一来，就需要处理依赖问题。
现在这样静态编译挺不适合低端硬件的嵌入式编程的。ram 和 rom 都较小的情况下，一库多用才是经济合理的。

gzdaijie

2020-12-13 21:33:59 +08:00 via Android

@wzw upx 带壳压缩，优点是仍可以直接运行，缺点是，运行时动态解压。不过实际应用过程中，解压感觉几乎是无影响的，所以对体积比较敏感的场合还是推荐用的，比如嵌入式设备。体积会影响加载和网络传输时间。通过编译选项减小体积是能提高性能的。

oxromantic

2020-12-13 21:38:14 +08:00

@gzdaijie 嵌入设备必须使用支持压缩的文件系统吧，这样 upx 也没必要了

gzdaijie

2020-12-13 21:45:20 +08:00 via Android

@oxromantic，嗯，这种是不需要的。但文件系统不是必须，嵌入式设备种类很多，家用路由器是，树莓派是，体积庞大的基站其实也是。不过因为体积和内存，Go 在这块的应用场景还非常有限，要求稍微高一点，就只能用 C 了。

CrazyBoyFeng

2020-12-13 21:47:53 +08:00

@CrazyBoyFeng 我查到 go 已经有动态链接编译的模式了，出来的 helloworld 只有 22kb，但是因为 go 几乎没有二进制依赖库管理机制，至今极难面向用户推行这种模式。

gzdaijie

2020-12-13 21:48:29 +08:00 via Android

@cabing 非常感谢你的建议，才刚刚开始写不久，通过讨论慢慢地拓宽视野。

gzdaijie

2020-12-13 21:53:28 +08:00 via Android

@CrazyBoyFeng 对的，动态链接是支持的，比如 cgo 编程，链接 C 库，类似于胶水。

CrazyBoyFeng

2020-12-13 22:03:54 +08:00

不过虽然动态编译 helloworld 只有 16kb，但是动态链接编译 go 标准库有 32mb 大小。如果应用少的话，可能还不如静态编译应用省空间。
http://z-rui.github.io/post/2016/07/golang-shared-library/
不知道有没有分模块编译动态库的方式，类似 python 那样。

raaaaaar

2020-12-13 22:15:14 +08:00 via Android

催一个 7 天

darksword21

2020-12-13 22:27:05 +08:00

🐎️住！

ShiningMage

2020-12-13 22:38:00 +08:00

标记一下

yixinlove

2020-12-13 23:09:15 +08:00

标记一下

jmyz0455

2020-12-13 23:57:35 +08:00

请问，go 写 web 好写吗？撸 crud 快吗？

gzdaijie

2020-12-14 00:14:57 +08:00 via Android

@jmyz0455 复杂的应用上，go 的生态比起 java 还是差挺多。简单网站区别不大。

yhzwy

2020-12-14 00:25:57 +08:00

go 一般是做什么领域的比较多业务开发方向的

gzdaijie

2020-12-14 00:35:04 +08:00 via Android

@yhzwy 可以多关注 go 比较知名的项目，微服务，系统编程(容器，数据库，文件系统等)，以及一些性能工具会比较多。

shoaly

2020-12-14 01:03:39 +08:00

@gzdaijie 感谢老哥给的压缩方案, 之前一直在找没找到.... 美滋滋

lewinlan

2020-12-14 02:00:08 +08:00 via Android

朋友，你的代码有不止一个问题啊。
比如 for 和 range 的性能比较那一段，二者根本就是不同的代码，当然性能有差距了。
建议再好好理解一下 range 的原理

Ehco1996

2020-12-14 07:29:53 +08:00 via iPhone

支持我是从 geeorm 入坑的哈哈

希望能讲讲网络相关的优化
比如 buffer poll，splice 特性之类的

Takamine

2020-12-14 08:01:57 +08:00 via Android

支持，我记得还有 Python 的坑，楼主别忘了。:doge:

gzdaijie

2020-12-14 08:29:07 +08:00 via Android

@lewinlan 哈哈，感谢你的建议。工作中的一些总结和尝试，大部分是自己的理解，错误在所难免，不过写之前也在尽可能多地参考。在讨论中慢慢完善和修正吧。早上刚合入了一个 PR 。

gzdaijie

2020-12-14 08:30:21 +08:00 via Android

@Ehco1996 嗯，网络异步 IO，多路复用这一块的确是比较某意思的。写法上接近 C 语言编程了。

gzdaijie

2020-12-14 08:31:23 +08:00 via Android

@Takamine 啊，这。。。过于细心了。

gzdaijie

2020-12-14 08:33:46 +08:00 via Android

@shoaly 哈哈，有场景用上了是最大的支持了～

gzdaijie

2020-12-14 08:47:01 +08:00 via Android

这个贴的批评和建议价值都很大。期待各位大大的 issue 和 PR 。今晚打算把 upx 这部分讨论，还有把有个老哥发起的静态链接的贴的内容传送门到博客中去，留个参考。

eudore

2020-12-14 08:51:38 +08:00

建议加上 sync.Pool 和 unsafe 两篇，都是常用的性能优化方法。

cnwlei

2020-12-14 08:59:45 +08:00

正在学 go,等我入门了再看 doge

hbolive

2020-12-14 08:59:54 +08:00

支持！

p1gd0g

2020-12-14 09:13:02 +08:00

Remember that "microbenchmark" is a synonym for "lie". There is no semantic difference between the two.

Shawdon

2020-12-14 09:16:54 +08:00

姿瓷

zhoudaiyu

2020-12-14 09:20:35 +08:00

虽然现在还看不懂，但是先收藏🐱

dany813

2020-12-14 09:29:33 +08:00

学

gzdaijie

2020-12-14 09:46:45 +08:00 via Android

@eudore 感谢建议，记下了。unsafe 数据库 bbolt 用得蛮多的，用来做内存映射和数据格式转换，有限减少内存拷贝。

teaaa

2020-12-14 09:48:01 +08:00

支持：）

gzdaijie

2020-12-14 09:48:38 +08:00 via Android

@p1gd0g 哈哈，这个观点有意思。在 benchmark 之外，找到一些理论支撑会好一些。不过表象本身也有一定的作用。

Yoock

2020-12-14 10:04:36 +08:00

已经在看了

zhuzhibin

2020-12-14 10:04:48 +08:00 via iPhone

7 天俺可以学会不

Caratpine

2020-12-14 10:25:42 +08:00

支持一下，很给力

b00tyhunt3r

2020-12-14 10:40:02 +08:00

马

f6x

2020-12-14 10:42:43 +08:00

文风简洁. +1

ai277014717

2020-12-14 10:48:26 +08:00

不错正在写 go 收藏一下

gzdaijie

2020-12-14 11:14:50 +08:00

@zhuzhibin 哈哈，每天 70 行代码，你可以的。借楼感谢下各位小伙伴。7 天系列的一开始也有很多 bug，感谢各位小伙伴在评论区的各种质疑和贡献，现在除了极少数没解决的 bug，其他部分的代码相对是比较精炼了。新项目也会积极收集大家的批评和建议，慢慢完善的。

gzdaijie

2020-12-14 11:21:43 +08:00

没来得及一一回复的小伙伴，发送感谢来表达我的谢意了。关于 benchmark 表象下的性能问题，突然想到最近在 BiliBili 看的王德峰老师的《资本论》，提到马克思的哲学革命，剥离范畴进行现象还原，蛮有意思的，比如两个高级灵长类动物在肉搏，不同范畴下就会有不同的事实表述，警匪之战，或是两人斗殴，或是其他，还可以顺便吸一口华子。

f6x

2020-12-14 12:08:28 +08:00

@gzdaijie 页面留言失败, 这里发给你吧. <如何退出协程>一文

* 2.1 代码应为 `done := make(chan bool, 1)`
* 部分场景可用 sync.WaitGroup 简化代码