Improve performance of BPF map buffer writes

[javierhonduco]

Using binary.Write to write to memory buffers we use to update BPF maps is not only using quite a bit of CPU cycles but also incurs quite a bit of small allocations. In particular, every single write performs an allocation.

This commit reduces allocations to 0 and CPU cycles by ~14x by writing to the buffer without performing any allocations. We do this with a new type, defined over a byte slice, which directly writes to the buffer using the lower-level binary APIs.

This also introduces two other advantages:

• The underlying array backing the slice will never grow in case of bugs. We want the buffers to be static and of exactly the size we expect in BPF.
• We can zero the buffers more efficiently. We need to do this to ensure that there is no stale information in the buffers we reuse.

This new type has to be used with care as we expect the Slice method to request a size equal or smaller to the available capacity.

Test Plan

Added unit tests, ran locally for a while with no issues and binary.Write barely showing up in the profiles. The new methods don't take much CPU either.

$ go test -v ./pkg/profiler/ -bench=. -count=30 > bench.txt

$ benchstat bench.txt
name                          time/op
EfficientBufferSliceWrite-12  2.18ns ± 4%
BinaryWrite-12                31.3ns ±26%

name                          alloc/op
EfficientBufferSliceWrite-12   8.00B ± 0%
BinaryWrite-12                 16.0B ± 0%

name                          allocs/op
EfficientBufferSliceWrite-12    0.00
BinaryWrite-12                  1.00 ± 0%

Part of #1286

Signed-off-by: Francisco Javier Honduvilla Coto javierhonduco@gmail.com

[brancz]

I think I would have personally wrapped the byte slice in a struct and kept a current index instead (I just find that a little easier to reason about), but this works perfectly well!

[kakkoyun]

❤️ 💚 💙 💛 💜