bucket: allow to allocate key on stack in Put()

[fyfyrchik]

While doing some bbolt optimizations for my usecase I have noticed key for Bucket.Get() and Bucket.Delete() can be allocated on stack, but when I add Bucket.Put() it cannot. While in reality it could, it seems to be hard for the go compiler.

go version go1.21.0 linux/amd64

As per go build -gcflags -m ./...:

Old behaviour:

./bucket.go:148:31: leaking param: key
./bucket.go:192:42: leaking param: key
./bucket.go:271:22: leaking param: key

Now:

./bucket.go:148:31: key does not escape
./bucket.go:192:42: key does not escape
./bucket.go:271:22: key does not escape

I have performed smoke tests on the benchmark from here #532, and got the expected results: 1 less allocation.

$ benchstat old new
seed: 42
goos: linux
goarch: amd64
pkg: go.etcd.io/bbolt
cpu: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz
                                 │     old     │              new              │
                                 │   sec/op    │   sec/op     vs base          │
Bucket_CreateBucketIfNotExists-8   4.820µ ± 1%   4.825µ ± 2%  ~ (p=1.000 n=10)

                                 │     old      │                 new                 │
                                 │     B/op     │     B/op      vs base               │
Bucket_CreateBucketIfNotExists-8   5.418Ki ± 0%   5.402Ki ± 0%  -0.29% (p=0.000 n=10)

                                 │    old     │                new                │
                                 │ allocs/op  │ allocs/op   vs base               │
Bucket_CreateBucketIfNotExists-8   32.00 ± 0%   31.00 ± 0%  -3.12% (p=0.000 n=10)

[cenkalti]

Cool! Can we have a short comment in code that explains why newKey var is introduced instead of reusing key?

[fyfyrchik]

Fixed, please, take a look.
BTW, #532 is also supposedly affected -- we might want to fix it there or here depending on the PR merge order.

[fyfyrchik]

I dived a bit deeper and it seems fixing this in compiler is not that easy (it is not run on SSA form yet, so all key are equal):
golang/go#18300

[ahrtr]

BTW, #532 is also supposedly affected -- we might want to fix it there or here depending on the PR merge order.

The PR #532 has already been merged. Please rebase this PR and fix it as well. thx

[ahrtr]

LGTM

Thank you! @fyfyrchik