perf: use fast unsafe bytes->string convertion

[robert-zaremba]

Avoid unnecessary allocation by using fast unsafe bytes -> string conversion

Notes:

• I didn't add conversions to the tests - I'm planning other PR there to cleanup key / values repetitions.

[tac0turtle]

could you provide some before and after benchmarks to verify the improvements

[robert-zaremba]

Benchmark:

benchmark                                old ns/op     new ns/op     delta
BenchmarkGetNonMembership/fast-16        143368        129285        -9.82%
BenchmarkGetNonMembership/regular-16     10305208      8466036       -17.85%
BenchmarkImmutableAvlTreeMemDB-16        150397        139207        -7.44%

benchmark                             old allocs     new allocs     delta
BenchmarkImmutableAvlTreeMemDB-16     437            392            -10.30%

benchmark                             old bytes     new bytes     delta
BenchmarkImmutableAvlTreeMemDB-16     33513         32100         -4.22%

[robert-zaremba]

turns out that it's significant optimization

[p0mvn]

Hi @robert-zaremba . Great work on this optimization. I had a couple of questions. Please let me know what you think

[p0mvn]

What do you think about the following to avoid copying the slice internals by directly casting the string:

func unsafeGetBytes(s string) []byte {
    return (*[0x7fff0000]byte)(unsafe.Pointer(
        (*reflect.StringHeader)(unsafe.Pointer(&s)).Data),
    )[:len(s):len(s)]
}

I'm not sure if there are any constraints preventing that but this could be a further optimization

[robert-zaremba]

What is [0x7fff0000]byte? Looks like a big static array. Where did you get that solution from?

[p0mvn]

It is the maximum process address space value

I grabbed this suggestion from here:
https://stackoverflow.com/questions/59209493/how-to-use-unsafe-get-a-byte-slice-from-a-string-without-memory-copy

Original source: https://groups.google.com/g/golang-nuts/c/Zsfk-VMd_fU/m/O1ru4fO-BgAJ

[p0mvn]

I'm surprised that this is helpful because, from my understanding, copying during []byte to string conversion when accessing a map by key should be optimized by the Go compiler.

Sources:

• cmd/gc: optimized map[string] lookup from []byte key golang/go#3512
• https://stackoverflow.com/questions/43470284/bytestring-vs-bytestring/43470344#43470344
• https://github.com/golang/go/blob/f5f5a8b6209f84961687d993b93ea0d397f5d5bf/src/cmd/gc/order.c#L943-L953

[p0mvn]

I'm wondering if the benchmark would remain the same as it is right now if the map[string] changes are reverted

[robert-zaremba]

I can check, however for consistency I prefer to keep the casting here.

[robert-zaremba]

After removing the fast convertion, there is a slight performance degradation:

• before = with unsafe string in cache.go maps
• after = with normal string(key) lookup in cache.go maps.

benchmark                             old ns/op     new ns/op     delta
BenchmarkImmutableAvlTreeMemDB-16     138184        140417        +1.62%

benchmark                             old allocs     new allocs     delta
BenchmarkImmutableAvlTreeMemDB-16     392            419            +6.89%

benchmark                             old bytes     new bytes     delta
BenchmarkImmutableAvlTreeMemDB-16     32154         32928         +2.41%

I repeated it few times and the memory allocation results were similar (there was more variation in the ns/op)

[p0mvn]

LGTM. Thanks for trying the map benchmarks.

Let's go with the approach that benchmarks show is best.

We can investigate this further separately