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