当前位置：首页 > news >正文

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

news 2025/8/4 2:53:12

背景

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

1. Slice扩容对性能的影响

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

func TestSliceBaseUsage(t *testing.T) {var slice []intslice = 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 := 1slice := 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 := 1var slice []intfor 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.capdoublecap := newcap + newcapif cap > doublecap {newcap = cap} else {const threshold = 256if 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}}}}