关于slice扩容性能损耗的探究

陪计算机走过漫长岁月

已于 2023-03-04 11:05:20 修改

阅读量383

点赞数

分类专栏： go 存储文章标签：数据结构

于 2023-03-04 10:44:56 首次发布

本文链接：https://blog.csdn.net/LuciferMS/article/details/129331612

版权

go 同时被 2 个专栏收录

12 篇文章 1 订阅

订阅专栏

存储

6 篇文章 0 订阅

订阅专栏

背景

如果让我评选最伟大的数据结构，在我心中答案只有两个，数组和哈希表，这两个是我的程序的重要组成部分，同时也是我饭碗的重要组成部分。slice和map简洁明了的API很容易让我们有一种他们提供了无限大的空间，可以容纳无限多的数据。然而，我们内心都有一面明镜，知道他们这些岁月静好的背后是通过扩容操作替我们负重前行。在nutsdb有slice和map来构建关键的数据结构或者处理数据，为了探究slice和map的使用对性能有没有影响，有多大影响，由此评估需不需要对这两个数据结构的使用方式进行优化。于是对slice和map扩容对性能的影响这个问题做了一些探究。总结出了一些文章。这是这个系列的第一篇文章。对slice扩容对性能的影响的研究。分享给大家。

1. Slice扩容对性能的影响

Slice是Go提供给我们的数据结构，基本上也是我们开发中最常用的数据结构了，在开发中使用过程一般是下面这样：

func TestSliceBaseUsage(t *testing.T) {
	var slice []int
	slice = append(slice, 1, 2, 3)
}

func TestSizedSliceBaseUsage(t *testing.T) {
  slice := make([]int, 10)
	slice = append(slice, 1, 2, 3)
}

第一种用法就是不指定切片的容量，用到哪里是哪里，第二种就是指定了容量，先申请一片空间，等用到了一定程度再继续扩容。那么他们两个之间到底有怎样的差异呢？我们来看看下面这段Benchmark测试。

func BenchmarkSlickGrow(b *testing.B) {
	// 要测试的切片长度
	var lengths = []int{1000, 10 * 1000, 100 * 1000, 1000 * 1000}
	for _, length := range lengths {
		// 直接申请空间的切片 性能测试
		nameOfNotGrowBM := fmt.Sprintf("test_slice_not_grow_%d", length)
		b.Run(nameOfNotGrowBM, func(b *testing.B) {
			b.ReportAllocs()
			b.StartTimer()
			for i := 0; i < b.N; i++ {
				value := 1
				slice := make([]int, length)
				for i := 0; i < length; i++ {
					slice = append(slice, value)
				}
			}
		})
		// 从一开始就不申请空间，一路append的切片 性能测试
		nameOfGrowBM := fmt.Sprintf("test_slice_grow_%d", length)
		b.Run(nameOfGrowBM, func(b *testing.B) {
			b.ReportAllocs()
			b.StartTimer()
			for i := 0; i < b.N; i++ {
				value := 1
				var slice []int
				for i := 0; i < length; i++ {
					slice = append(slice, value)
				}
			}
		})
	}
}

这个benchmark测试了从长度数量级为一千到一百万的切片，直接申请空间然后逐渐添加元素和不申请空间通过append添加元素这两种操作之间的性能对比。我们跑一下这个代码来看看结果：

goos: darwin
goarch: arm64
pkg: go-learn/go
BenchmarkSlickGrow
BenchmarkSlickGrow/test_slice_not_grow_1000
BenchmarkSlickGrow/test_slice_not_grow_1000-10         	  242797	      4759 ns/op	   38912 B/op	       3 allocs/op
BenchmarkSlickGrow/test_slice_grow_1000
BenchmarkSlickGrow/test_slice_grow_1000-10             	  304522	      3619 ns/op	   25208 B/op	      12 allocs/op
BenchmarkSlickGrow/test_slice_not_grow_10000
BenchmarkSlickGrow/test_slice_not_grow_10000-10        	   16395	     71704 ns/op	  507905 B/op	       4 allocs/op
BenchmarkSlickGrow/test_slice_grow_10000
BenchmarkSlickGrow/test_slice_grow_10000-10            	   22346	     52807 ns/op	  357626 B/op	      19 allocs/op
BenchmarkSlickGrow/test_slice_not_grow_100000
BenchmarkSlickGrow/test_slice_not_grow_100000-10       	    1620	    729987 ns/op	 6635538 B/op	       5 allocs/op
BenchmarkSlickGrow/test_slice_grow_100000
BenchmarkSlickGrow/test_slice_grow_100000-10           	    2632	    468636 ns/op	 4101390 B/op	      28 allocs/op
BenchmarkSlickGrow/test_slice_not_grow_1000000
BenchmarkSlickGrow/test_slice_not_grow_1000000-10      	     308	   3843628 ns/op	65708071 B/op	       5 allocs/op
BenchmarkSlickGrow/test_slice_grow_1000000
BenchmarkSlickGrow/test_slice_grow_1000000-10          	     360	   3247562 ns/op	41678130 B/op	      38 allocs/op
PASS

从测试结果来看，不扩容的测试组性能上，内存上，比起扩容的测试组，领先优势起码拉开了一个身位。

1000这个档位，速度上不扩容比扩容快约30%，内存上不扩容比扩容省50%
10,000这个档位，速度上不扩容比扩容快约36%，内存上不扩容比扩容省42%
100,000这个档位，速度上不扩容比扩容快约18%，内存上不扩容比扩容省20%

为什么会造成这个样子的结果呢？让我们来看看slice的扩容原理。

func growslice(et *_type, old slice, cap int) slice {
	newcap := old.cap
	doublecap := newcap + newcap
	if cap > doublecap {
		newcap = cap
	} else {
		const threshold = 256
		if old.cap < threshold {
			newcap = doublecap
		} else {
			// Check 0 < newcap to detect overflow
			// and prevent an infinite loop.
			for 0 < newcap && newcap < cap {
				// Transition from growing 2x for small slices
				// to growing 1.25x for large slices. This formula
				// gives a smooth-ish transition between the two.
				newcap += (newcap + 3*threshold) / 4
			}
			// Set newcap to the requested cap when
			// the newcap calculation overflowed.
			if newcap <= 0 {
				newcap = cap
			}
		}
	}
	}