Efficient allocation of slices (cap vs length)

问题

Assuming I am creating a slice, which I know in advance that I want to populate via a for loop with 1e5 elements via successive calls to append:

// Append 1e5 strings to the slice

for i := 0; i<= 1e5; i++ {
    value := fmt.Sprintf("Entry: %d", i)
    myslice = append(myslice, value)
}

which is the more efficient way of initialising the slice and why:

a. declaring a nil slice of strings?

var myslice []string

b. setting its length in advance to 1e5?

myslice = make([]string, 1e5)

c. setting both its length and capacity to 1e5?

myslice = make([]string, 1e5, 1e5)

回答1:

Your b and c solutions are identical: creating a slice with make() where you don't specify the capacity, the "missing" capacity defaults to the given length.

Also note that if you create the slice with a length in advance, you can't use append() to populate the slice, because it adds new elements to the slice, and it doesn't "reuse" the allocated elements. So in that case you have to assign values to the elements using an index expression, e.g. myslice[i] = value.

If you start with a slice with 0 capacity, a new backing array have to be allocated and "old" content have to be copied over whenever you append an element that does not fit into the capacity, so that solution must be slower inherently.

I would define and consider the following different solutions (I use an []int slice to avoid fmt.Sprintf() to intervene / interfere with our benchmarks):

var s []int

func BenchmarkA(b *testing.B) {
    for i := 0; i < b.N; i++ {
        s = nil
        for j := 0; j < 1e5; j++ {
            s = append(s, j)
        }
    }
}

func BenchmarkB(b *testing.B) {
    for i := 0; i < b.N; i++ {
        s = make([]int, 0, 1e5)
        for j := 0; j < 1e5; j++ {
            s = append(s, j)
        }
    }
}

func BenchmarkBLocal(b *testing.B) {
    for i := 0; i < b.N; i++ {
        s := make([]int, 0, 1e5)
        for j := 0; j < 1e5; j++ {
            s = append(s, j)
        }
    }
}

func BenchmarkD(b *testing.B) {
    for i := 0; i < b.N; i++ {
        s = make([]int, 1e5)
        for j := range s {
            s[j] = j
        }
    }
}

Note: I use package level variables in benchmarks (except BLocal), because some optimization may (and actually do) happen when using a local slice variable).

And the benchmark results:

BenchmarkA-4         1000     1081599 ns/op     4654332 B/op     30 allocs/op
BenchmarkB-4         3000      371096 ns/op      802816 B/op      1 allocs/op
BenchmarkBLocal-4   10000      172427 ns/op      802816 B/op      1 allocs/op
BenchmarkD-4        10000      167305 ns/op      802816 B/op      1 allocs/op

A: As you can see, starting with a nil slice is the slowest, uses the most memory and allocations.

B: Pre-allocating the slice with capacity (but still 0 length) and using append: it requires only a single allocation and is much faster, almost thrice as fast.

BLocal: Do note that when using a local slice instead of a package variable, (compiler) optimizations happen and it gets a lot faster: twice as fast, almost as fast as D.

D: Not using append() but assigning elements to a preallocated slice wins in every aspect, even when using a non-local variable.

回答2:

For this use case, since you already know the number of string elements that you want to assign to the slice,

I would prefer approach b or c.

Since you will prevent resizing of the slice using these two approaches.

If you choose to use approach a, the slice will double its size everytime a new element is added after len equals capacity.

https://play.golang.org/p/kSuX7cE176j

来源：https://stackoverflow.com/questions/56490051/efficient-allocation-of-slices-cap-vs-length

标签

slice