性能优化

性能优化建议

性能优化的前提是满足正确可靠、简洁清晰等质量因素

性能优化是综合评估，有时候时间效率和空间效率可能对立

针对 Go 语言特性，介绍 Go 相关的性能优化建议

Benchmark

如何使用？

1.性能表现需要实际数据衡量

2.Go 语言提供了支持基准性能测试的 benchmark 工具

go test -bench=. -benchmem

Slice

slice预分配内存

尽可能在使用make（）初始化切片时提供容量信息

func NoPreAlloc(size int){
    data := make([]int, 0)
    for k := 0;k < size; k++{
        data = append(data, k)
    }
}

func PreAlloc(size int){
    data := make([]int, 0, size)
    for k := 0; k < size; k++{
        data = append(data, k)
    }
}

1.切片本质是一个数组片段的描述 ①包括数组指针 ②片段的长度 ③片段的容量(不改变内存分配情况下的最大长度)

2.切片操作并不复制切片指向的元素

3.创建一个新的切片会复用原来切片的底层数组

type slice struct {
	array unsafe.Pointer
    len int
    cap int
}

另一个陷阱：大内存未释放

在已有切片基础上创建切片，不会创建新的底层数组

场景 1.原切片较大，代码在原切片基础上新建小切片 2.原底层数组在内存中有引用，得不到释放

可使用 copy 替代 re-slice

Map

map预分配内存

不断向 map 中添加元素的操作会触发 map 的扩容

提前分配好空间可以减少内存拷贝和 Rehash 的消耗

建议根据实际需求提前预估好需要的空间

字符串处理

使用strings.Builder

func ByteBuffer(n int, str string) string{
    buf := new(bytes.Buffer)
    for i := 0; i < n;i++{
        buf.WriteString(str)
    }
    return buf.String()
}

使用 + 拼接性能最差，strings.Builder，bytes.Buffer 相近，strings.Buffer 更快

分析 1.字符串在 Go 语言中是不可变类型，占用内存大小是固定的 2.使用 + 每次都会重新分配内存 3.strings.Builder，bytes.Buffer 底层都是 []byte 数组 4.内存扩容策略，不需要每次拼接重新分配内存

为什么`string.Builder`要快？

1.bytes.Buffer 转化为字符串时重新申请了一块空间 2.strings.Builder 直接将底层的[]byte 转换成了字符串类型返回

空结构体

使用空结构体节省内存

1.空结构体 struct{} 实例不占据任何的内存空间

2.可作为各种场景下的占位符 ①使用节省资源 ②空结构体本身具备很强的语义，即这里不需要任何值，仅作为占位符

func EmptyStructMap(n int) {
    m := make(map[int]struct{})
    for i :=0; i < n; i++{
        m[i] = struct{}{}
    }
}

实现 Set，可以考虑用 map 来代替

对于这个场景，只需要用到 map 的键，而不需要值

即使是将 map 的值设置为 bool 类型，也会多占据 1 个字节空间

atomic包

锁的实现是通过操作系统来实现，属于系统调用

atomic 操作是通过硬件实现，效率比锁高

sync.Mutex 应该用来保护一段逻辑，不仅仅用于保护一个变量

对于非数值操作，可以使用 atomic.Value，能承载一个 interface{}

性能优化｜ 青训营