这是我参与「第五届青训营」伴学笔记创作活动的第 2 天

Go 语言性能优化建议

简介

高质量的代码能够完成功能，但是在大规模程序部署的场景，仅仅支持正常功能还不够，我们还要尽可能的提升性能，节省资源成本，接下来就主要介绍性能相关的建议。

性能优化的前提是满足正确可靠、简洁清晰等质量因素
性能优化是综合评估，有时候时间效率和空间效率可能对立
针对 Go 语言特性，本文记录 Go 相关的性能优化建议

Benchmark

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

go test -bench=. -benchmem

以计算斐波拉契数列的函数为例，分两个文件，fib.go编写函数代码,fib_test.go编写benchmark的逻辑，通过命令运行benchmark可以得到测试结果。-benchmem表示也统计内存信息。

func Fib(n int) int {
    if n < 2 {
        return n
    }
    return Fib(n-1) + Fib(n-2)
}

// from fib test.go
func BenchmarkFib10(b *testing.B) {
    // run the Fib function b.N times
    for n : = 0; n < b. N; n++ {
        Fib(10)
    }
}

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([lint, 0, size)
    for k : = 0; k < size; k++ {
        data = append(data, k)
    }
}

结果说明

在追加切片时对比看下两种情况的性能表现。结果中可以看出执行时间相差很多，预分配只有一次内存分配。

截屏2023-01-17 15.16.48.png

可能出现这么一种情况，原切片由大量的元素构成，但是我们在原切片的基础上切片，虽然只使用了很小一段，但底层数组在内存中仍然占据了大量空间，得不到释放。可使用 copy 替代 re-slice

func GetLastBySlice(origin []int) []int {
    return origin[len(origin)-2:]
}

func GetLastByCopy(origin []int) []int {
    result := make([]int, 2)
    copy(result, origin[len(origin)-2:])
    return result
}

// 测试程序
func testGetLast(t *testing.T, f func([]int) []int) {
    result := make([][]int, 0)
    for k:= 0; k < 100; k++ {
        origin := generateWithCap(128 * 1024) // IM
        result = append(result, f(origin))
    }
    printMem(t)
    _ = result
}

结果说明

lastBySlice 耗费了 100.14 MB 内存，也就是说，申请的 100 个 1MB 大小的内存没有被回收。因为切片虽然只使用了最后 2 个元素，但是因为与原来 1M 的切片引用了相同的底层数组，底层数组得不到释放，因此，最终 100MB 的内存始终得不到释放。

而 lastByCopy 仅消耗了 3.14MB 的内存。这是因为，通过 copy，指向了一个新的底层数组，当 origin 不再被引1用后，内存会被垃圾回收。

Map优化

预分配，尽可能在使用 make()初始化切片时提供容量信息。

分析: 不断向 map 中添加元素的操作会触发 map 的扩容, 提前分配好空间可以减少内存拷贝和 Rehash 的消耗, 建议根据实际需求提前预估好需要的空间

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

字符串处理优化

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

// 当使用 ＋ 拼接 2 个字符串时，需要开辟一段新的空间，空间大小是原来两个字符串的大小之和。
func Plus(n int, str string) string {
    s := ""
    for i := 0; i < n; i++ {
        s += str
    }
    return s
}

// strings.Builder， bytes.Buffer 底层都是 []byte 数组
// 内存扩容策略，不需要每次拼接重新分配内存
func StrBuilder(n int, str string) string {
    var builder strings.Builder
    for i := 0; i < n; i++ {
        builder.WriteString(str)
    }
    return builder.String()
}

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

为什么stringbuilder会比bytebuffer更快一些？bytes.Buffer 转化为字符串时重新申请了一块空间，strings.Builder 直接将底层的 []byte 转换成了字符串类型返回

字符串拼接和 slice 一样，同样支持预分配，在预知长度的情况下，我们可以进一步提升拼接性能

// stringbuiler 只有一次内存分配
func PreStrBuilder(n int, str string) string {
    var builder strings.Builder
    builder.Grow(n * len(str))
    for i := 0; i < n; i++ {
        builder.WriteString(str)
    }
    return builder. String()
}

// bytebuffer 有两次内存分配
func PreByteBuffer(n int, str string) string {
    buf := new(bytes.Buffer)
    buf.Grow(n * len(str))
    for i := 0; i < n; i++ {
        buf.WriteString(str)
    }
    return buf.String()
}

结果说明

截屏2023-01-17 15.18.33.png

使用空结构体优化

使用空结构体节省内存

空结构体 struct 实例不占据任何的内存空间
可作为各种场景下的占位符使用
节省资源
空结构体本身具备很强的语义，即这里不需要任何值，仅作为占位符

应用

实现 Set，可以考虑用 map 来代替
对于这个场景，只需要用到 map 的键，而不需要值
即使是将 map 的值设置为 bool 类型，也会多占据 1 个字节空间

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

atomic 包

多线程编程的场景，比如实现一个多线程共用的计数器，如何保证计数准确，线程安全，有不同的方式

// 使用 atomic 包实现线程安全
type atomicCounter struct {
    i int32
}

func AtomicAddOne(c *atomicCounter) {
    atomic.AddInt32(&c.i, 1)
}

// 使用 mutex 锁实现线程安全
type mutexCounter struct {
    i int32
    m sync.Mutex
}

func MutexAddOne(c *mutexCounter) {
    c.m.Lock()
    c.i++
    c.m.Unlock()
}

结果说明

截屏2023-01-17 15.18.59.png

锁的实现是通过操作系统来实现，属于系统调用
atomic 操作是通过硬件实现，效率比锁高
sync.Mutex 应该用来保护一段逻辑，不仅仅用于保护一个变量
对于非数值操作，可以使用 atomic.Value，能承载一个 interface{}

总结

避免常见的性能陷阱可以保证大部分程序的性能
普通应用代码，不要一味地追求程序的性能
越高级的性能优化手段越容易出现问题
在满足正确可靠、简洁清晰的质量要求的前提下提高程序性能

1月16日Day2 Go语言性能优化建议｜青训营笔记

Go 语言性能优化建议

简介

Benchmark

Slice优化

结果说明

结果说明

Map优化

字符串处理优化

结果说明

使用空结构体优化

应用

atomic 包

结果说明

总结