Closed adam-talos closed 5 months ago
…in golang 1.22
Verify by running
go build -gcflags=all=-d=loopvar=2
When compiling in Golang 1.22, the loop behavior has changed and the code generated by SBE in Go can suddenly allocate to the heap.
You can verify this by running
Before the generated could would look like
for _, prop := range m.Entries { if err := prop.Encode(_m, _w); err != nil { return err } }
This reference to prop could potentially allocate if prop.Encode could not be inlined.
The new code that is generated uses the index to get the reference, which will not allocate.
for i := range m.Entries { if err := m.Entries[i].Encode(_m, _w); err != nil { return err } }
…in golang 1.22
Verify by running
When compiling in Golang 1.22, the loop behavior has changed and the code generated by SBE in Go can suddenly allocate to the heap.
You can verify this by running
Before the generated could would look like
This reference to prop could potentially allocate if prop.Encode could not be inlined.
The new code that is generated uses the index to get the reference, which will not allocate.