core/rawdb: allocate database keys with explicit size to avoid slice growth

[MariusVanDerWijden]

During profiling I noticed that a lot of allocations are spent trying to compute the keys for accessing the database:

ROUTINE ======================== github.com/ethereum/go-ethereum/core/rawdb.storageSnapshotKey in github.com/ethereum/go-ethereum/core/rawdb/schema.go
 288552922  288552922 (flat, cum)  2.96% of Total
         .          .    197:func storageSnapshotKey(accountHash, storageHash common.Hash) []byte {
 288552922  288552922    198:	return append(append(SnapshotStoragePrefix, accountHash.Bytes()...), storageHash.Bytes()...)
         .          .    199:}
         .          .    200:
         .          .    201:// storageSnapshotsKey = SnapshotStoragePrefix + account hash + storage hash
         .          .    202:func storageSnapshotsKey(accountHash common.Hash) []byte {
         .          .    203:	return append(SnapshotStoragePrefix, accountHash.Bytes()...)
ROUTINE ======================== github.com/ethereum/go-ethereum/core/rawdb.storageTrieNodeKey in github.com/ethereum/go-ethereum/core/rawdb/schema.go
 193875095  193875095 (flat, cum)  1.99% of Total
         .          .    261:func storageTrieNodeKey(accountHash common.Hash, path []byte) []byte {
 193875095  193875095    262:	return append(append(trieNodeStoragePrefix, accountHash.Bytes()...), path...)
         .          .    263:}
         .          .    264:
         .          .    265:// IsLegacyTrieNode reports whether a provided database entry is a legacy trie
         .          .    266:// node. The characteristics of legacy trie node are:
         .          .    267:// - the key length is 32 bytes

This PR reduces the number of allocs, and increases the speed of creating these keys

Benchmarks (the suffix 2 denotes the new ones):

BenchmarkStorageSnapshot-24    	14854363	        99.08 ns/op	     144 B/op	       2 allocs/op
BenchmarkStorageSnapshot2-24    	1000000000	         0.2276 ns/op	       0 B/op	       0 allocs/op
BenchmarkStorageTrieNodeKey-24    	19944460	        97.97 ns/op	     144 B/op	       2 allocs/op
BenchmarkStorageTrieNodeKey2-24    	40256310	        49.82 ns/op	      80 B/op	       1 allocs/op

[jsvisa]

Suggested change

	res := make([]byte, 1+len(accountHash)*2)
	res := make([]byte, len(SnapshotStoragePrefix)+common.HashLength*2)

[jsvisa]

Suggested change

	res := make([]byte, 1+len(accountHash)+len(path))
	res := make([]byte, len(trieNodeStoragePrefix)+common.HashLength+len(path))

[rjl493456442]

Suggested change

	res := make([]byte, 1+len(accountHash)+len(path))
	buf := make([]byte, len(trieNodeStoragePrefix)+common.HashLength+len(path))
	n := copy(buf, trieNodeStoragePrefix)
	n += copy(buf[n:], accountHash.Bytes())
	copy(buf[n:], path)
	return buf

could be something like this

[holiman]

I suspect that a more minimal change would have the same effect

Suggested change

	buf := make([]byte, len(SnapshotStoragePrefix)+common.HashLength+common.HashLength)
	n := copy(buf, SnapshotStoragePrefix)
	n += copy(buf[n:], accountHash.Bytes())
	copy(buf[n:], storageHash.Bytes())
	return buf
	buf := make([]byte, 0, len(SnapshotStoragePrefix)+common.HashLength+common.HashLength)
	return append(append(append(buf, SnapshotStoragePrefix...), accountHash.Bytes()...), storageHash.Bytes()...)

It is slightly less complex since it relies on the compiler instead of fiddling with n.