- 博客(11)
- 收藏
- 关注
原创 Go: Readonly Variable
只读变量的缺失,应该算 Go 语言 “设计缺陷”。举例来说,默认以 error 实例来判断错误类别,但这些可导出全局变量实际可被外部修改,那么就存在隐性风险。
2016-05-06 20:59:03
1144
原创 Go 性能优化技巧 9/10
作为内置类型,通道(channel)从运行时得到很多支持,其自身设计也算得上精巧。但不管怎么说,它本质上依旧是一种队列,当多个 goroutine 并发操作时,免不了要使用锁。某些时候,这种竞争机制,会导致性能问题。
2016-05-04 13:50:57
788
原创 Go 性能优化技巧 8/10
尽管反射(reflect)存在性能问题,但依然被频繁使用,以弥补静态语言在动态行为上的不足。只是某些时候,我们须对此做些变通,以提升性能。
2016-05-04 13:45:04
551
原创 Go 性能优化技巧 7/10
接口的用途无需多言。但这并不意味着可在任何场合使用接口,要知道通过接口调用和普通调用存在很大差别。首先,相比静态绑定,动态绑定性能要差很多;其次,运行期需额外开销,比如接口会复制对象,哪怕仅是个指针,也会在堆上增加一个需 GC 处理的目标。显然,对于压力很大的内部组件之间,用接口有些得不偿失。对比接口调用和普通调用的汇编指令,以便有个直观的认识。普通
2016-05-04 13:41:46
404
原创 Go 性能优化技巧 6/10
Go 使用 channel 实现 CSP 模型。处理双方仅关注通道和数据本身,无需理会对方身份和数量,以此实现结构性解耦。在各文宣中都有 “Don't communicate by sharing memory, share memory by communicating.” 这类说法。但这并非鼓励我们不分场合,教条地使用 channel。
2016-05-04 13:36:35
586
原创 Go 性能优化技巧 4/10
延迟调用(defer)确实是一种 “优雅” 机制。可简化代码,并确保即便发生 panic 依然会被执行。如将 panic/recover 比作 try/except,那么 defer 似乎可看做 finally。
2016-05-04 13:28:55
554
原创 Go 性能优化技巧 3/10
内置 map 类型是必须的。首先,该类型使用频率很高;其次,可借助 runtime 实现深层次优化(比如说字符串转换,以及 GC 扫描等)。可尽管如此,也不意味着万事大吉,依旧有很多需特别注意的地方。
2016-05-04 13:09:58
2118
原创 Go 性能优化技巧 2/10
对于一些初学者,自知道 Go 里面的 array 以 pass-by-value 方式传递后,就莫名地引起 “恐慌”。外加诸多文章未作说明,就建议用 slice 代替 array,企图避免数据拷贝,提升性能。实际上,此做法有待商榷。某些时候怕会适得其反,倒造成不必要的性能损失。
2016-05-04 12:34:28
492
原创 Go性能优化技巧 1/10
字符串(string)作为一种不可变类型,在与字节数组(slice, [ ]byte)转换时需付出 “沉重” 代价,根本原因是对底层字节数组的复制。这种代价会在以万为单位的高并发压力下迅速放大,所以对它的优化常变成 “必须” 行为。
2016-05-04 11:39:35
536
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人