Ineffective breaks in heap_manager.go about mpb HOT 3 CLOSED

I meant the var buffer [64]byte version. Take a look at https://go.dev/play/p/0ig2yQgA3gg.

Benchmark results:

name              time/op
Append_Pooled-32  214ns ± 5%
Append_Stack-32   202ns ± 1%
Append_Alloc-32   201ns ± 0%

Also, avoiding the pool is also going to less code and easier to reason about.

While reviewing the code, I realized that that it's always putting back the small slice, so there's no problem with holding on to a potentially large slices.

from mpb.

I was looking through the codebase and when running staticcheck it lists these issues:

Yep, staticcheck's suggestion is right, despite current behavior doesn't lead to any bugs.

Other things I noticed that aren't errors per se, but looked unusual to me:

Thankfully I left a comment strip off nanoseconds. I agree that Truncate func is better option here, thanks for suggestion.

using a var buffer [64]byte should get you most of the way and avoid scenarios where you accidentally pool large []byte values for a long time.

It's used to feed strconv.AppendFloat with dst []byte param. Did you mean to increase cap to 64 like b := make([]byte, 0, 64) or using array [64]byte instead of slice? If latter then how can it help/improve?

from mpb.

Addressed in v8.4.0.

from mpb.