I’m actually surprised. Completely did not expect the smaller allocation to make any difference. Since the only difference should be the initialisation time… that sounds like a lot of time for simple clears. Unless there’s more page faulting than I would expect.

The next improvement then would be to preallocate that slice and clear instead of making a new one.

So the accounting of “alloc”s seem weird to me. Here are 4 extra variants:

Benchmark1          1224            899297 ns/op           30092 B/op        218 allocs/op
Benchmark2           640           1803190 ns/op           18012 B/op         24 allocs/op
Benchmark3         24681             46804 ns/op           17416 B/op          8 allocs/op
Benchmark4          2342            440008 ns/op           17418 B/op          8 allocs/op

1 is original, 2 is original with clear instead of make, 3 is slice, 4 is slice with clear instead of make.

I feel like this will need some deep dive to understand how make is better optimised than a loop clearing the values. And why does benchmark 4 have the same number of allocs as 3.

And why is the difference so large for clearing? Clearing 256 bytes of data should be trivial, unless go doesn’t optimise that loop at all…

It’s possible to exploit the fact that inputs to hasDuplicates function are always of a known fixed size, and avoid extra allocation like this:

const width = 14

func hasDuplicates(bb []byte) bool {
	if len(bb) != width {
		panic(fmt.Errorf("want []byte of len %d, got %d", width, len(bb)))
	}
	var x uint64
	for _, b := range bb {
		x |= (1 << (b - 'a' - 1))
	}
	return bits.OnesCount64(x) == width
}

Same result, but we use a single uint64 as a bitmap.

I would’ve liked to see [256]bool included and see whether avoiding the heap allocation entirely helped.

This is a repost.