process: reuse and preallocate memory

[florianl]

No description provided.

[rockdaboot]

Can you add memory allocations for before and after?

[florianl]

Updated benchmark on 4b538b5:

$ benchstat old.txt new.txt 
goos: linux
goarch: amd64
pkg: go.opentelemetry.io/ebpf-profiler/process
cpu: 12th Gen Intel(R) Core(TM) i7-12700H
               │   old.txt   │               new.txt               │
               │   sec/op    │   sec/op     vs base                │
GetMappings-20   37.14µ ± 1%   38.01µ ± 1%  +2.34% (p=0.000 n=10)

               │    old.txt    │               new.txt               │
               │     B/op      │     B/op      vs base               │
GetMappings-20   10.574Ki ± 0%   9.605Ki ± 0%  -9.16% (p=0.000 n=10)

               │  old.txt   │              new.txt               │
               │ allocs/op  │ allocs/op   vs base                │
GetMappings-20   28.00 ± 0%   24.00 ± 0%  -14.29% (p=0.000 n=10)

BenchmarkGetMappings

func BenchmarkGetMappings(b *testing.B) {
	pr := New(libpf.PID(os.Getpid()))
	b.ResetTimer()
	b.ReportAllocs()

	for i := 0; i < b.N; i++ {
		mappings, err := pr.GetMappings()
		if err != nil {
			b.Fatal(err)
		}
		if len(mappings) == 0 {
			b.Fatal("expected non-empty mappings")
		}
	}
}

[florianl]

Updated benchmark on 4b538b5:

$ benchstat old.txt new.txt 
goos: linux
goarch: amd64
pkg: go.opentelemetry.io/ebpf-profiler/process
cpu: 12th Gen Intel(R) Core(TM) i7-12700H
                 │   old.txt   │              new.txt               │
                 │   sec/op    │   sec/op     vs base               │
ParseMappings-20   202.4µ ± 2%   204.4µ ± 5%  +0.97% (p=0.009 n=10)

                 │   old.txt    │               new.txt               │
                 │     B/op     │     B/op      vs base               │
ParseMappings-20   164.7Ki ± 0%   162.3Ki ± 0%  -1.48% (p=0.000 n=10)

                 │  old.txt   │              new.txt              │
                 │ allocs/op  │ allocs/op   vs base               │
ParseMappings-20   444.0 ± 0%   438.0 ± 0%  -1.35% (p=0.000 n=10)

BenchmarkParseMappings

func BenchmarkParseMappings(b *testing.B) {
    // Get sample data from current process
    mapsFile, err := os.Open(fmt.Sprintf("/proc/%d/maps", os.Getpid()))
    if err != nil {
        b.Fatal(err)
    }
    defer mapsFile.Close()
    
    // Read all content for reuse in benchmark
    content, err := io.ReadAll(mapsFile)
    if err != nil {
        b.Fatal(err)
    }

    b.ResetTimer()
    b.ReportAllocs()
    
    for i := 0; i < b.N; i++ {
        reader := bytes.NewReader(content)
        mappings, err := parseMappings(reader)
        if err != nil {
            b.Fatal(err)
        }
        if len(mappings) == 0 {
            b.Fatal("expected non-empty mappings")
        }
    }
}

[rockdaboot]

On a second thought... why clear the memory at all here? parseMapping() does not rely on the contents of the buffer retrieved from the pool. The scanner read data and only acts on the read data in the buffer. It doesn't matter if we fill the bufferswith 0 bytes or random bytes or leave it as is.

Suggested change

	// Reset memory and return it for reuse.
	for j := 0; j < len(*scanBuf); j++ {
	(*scanBuf)[j] = 0x0
	}

[florianl]

The scanner, that uses this buffer, uses the default split function ScanLines. By not clearing the buffer, we might introduce subtle bugs.

[rockdaboot]

we might introduce subtle bugs

Possibly yes. Can you add a test case that triggers such a bug. That makes it obvious to if someone ever touches that code or wonders if it is required.

[rockdaboot]

Hm, I can't see how bufio.Scanner.Scan() uses ScanLines().

[florianl]

As we don't set a specific Split function, the buffer uses the default https://pkg.go.dev/bufio#NewScanner.

[christos68k]

If we're not sure, I'd rather we clear the buffer than introduce a subtle bug. The performance implications here should be minimal to non-existent.

[rockdaboot]

I see no indication of subtle bugs here (the std library code is pretty clear). If you think there are, please add a test case to catch it. The split function only operates on the bytes that have been read by Read(), so whatever bytes we set to 0, they will be overwritten before being acted upon. I don't think we should introduce code because "there could be bugs inside the std library", that isn't fact-driven development.

[florianl]

I have reverted the applied suggestion, as I should not have applied in the first place. And I also reasked for review.
I have reverted the applied suggestion as resetting a buffer before reusing is something I will ask in a review, until it is shown that the operation can be done correctly with every state of the buffer. And this proposed change does not show that it will work as supposed with every state of the shared buffer.

[rockdaboot]

I still didn't see any argument why or what exactly can fail. Without an explicit statement it is not possible to create a test case. Can't we just go with the facts instead of having some vague "fear"?