[BUG][GO]: //go:inline pragmas are no-ops — hot-path functions not being inlined

[ayush00git]

Search before asking

• I had searched in the issues and found no similar issues.

Version

Current

Component(s)

Go

It was introduced in the PR #3071

Minimal reproduce step

Run go build -gcflags='-m -m'
Output -

buffer.go:71:  cannot inline (*ByteBuffer).WriteByte:   cost 86 > budget 80
buffer.go:86:  cannot inline (*ByteBuffer).WriteInt8:   cost 85 > budget 80
buffer.go:114: cannot inline (*ByteBuffer).WriteUint32: cost 85 > budget 80
buffer.go:121: cannot inline (*ByteBuffer).WriteInt32:  cost 86 > budget 80
buffer.go:199: cannot inline (*ByteBuffer).ReadByte:    cost 94 > budget 80
buffer.go:251: cannot inline (*ByteBuffer).ReadUint32:  cost 96 > budget 80
buffer.go:264: cannot inline (*ByteBuffer).ReadUint64:  cost 96 > budget 80

Summary

buffer.go uses //go:inline on functions. This is not a valid Go compiler directive — the standard gc compiler silently ignores it. As a result, critical hot-path functions like WriteInt32, ReadByte, ReadUint64 etc. are not being inlined, paying full function call overhead on every invocation.

Root Cause

• Write functions: the grow() call adds enough cost (~40) to push the total over 80.
• Read functions: the inline BufferOutOfBoundError() construction adds ~15–20 cost, pushing totals to 94–97.

Proposed Fix

1. Remove all //go:inline pragmas — they are no-ops and misleading.
2. Write path: inline the fast-path bounds check directly and keep only growSlow() as //go:noinline:

   func (b *ByteBuffer) WriteInt8(value int8) {
       if b.writerIndex+1 > len(b.data) {
           b.growSlow(1)
       }
       b.data[b.writerIndex] = byte(value)
       b.writerIndex++
   }

3. Read path: move error construction to a //go:noinline cold-path helper:

   func (b *ByteBuffer) ReadInt8(err *Error) int8 {
       if b.readerIndex+1 > len(b.data) {
           b.readBoundsError(err, 1)
           return 0
       }
       v := int8(b.data[b.readerIndex])
       b.readerIndex++
       return v
   }
   
   //go:noinline
   func (b *ByteBuffer) readBoundsError(err *Error, n int) {
       *err = BufferOutOfBoundError(b.readerIndex, n, len(b.data))
   }

Both changes bring function costs well under 80, enabling automatic compiler inlining with no pragmas needed.

Impact

These are the most frequently called functions in the entire serialization pipeline. Enabling inlining eliminates function call overhead (stack frame, argument spilling) on every primitive read/write operation.

Are you willing to submit a PR?

• I'm willing to submit a PR!

[ayush00git]

Hii @chaokunyang
Have a look at the issue and let me know is it right to begin?

[chaokunyang]

I think remove //go:noinline from growSlow only would be enough. Could you check whether it will work?

[ayush00git]

Removing //go:noinline from growSlow() does fix the write path, drops from cost 85 → 75, now under budget. However, the read path functions are unaffected because their cost comes from the inline BufferOutOfBoundError() construction, not from grow(). We still need to move the error construction to a //go:noinline helper to fix those.

Also, the //go:inline comments throughout the file can be removed — the gc compiler doesn't recognize //go:inline as a directive. It automatically inlines any function with cost under 80.

[ayush00git]

Here are the outputs after i removed the //go:noinline from growSlow() -

./buffer.go:49:6: can inline (*ByteBuffer).growSlow with cost 47 as: method(*ByteBuffer) func(int) { needed := b.writerIndex + n; if needed <= cap(b.data) { b.data = b.data[:cap(b.data)] } else { newCap := 2 * needed; newBuf := make([]byte, newCap); copy(newBuf, b.data[:b.writerIndex]); b.data = newBuf } }
./buffer.go:40:6: can inline (*ByteBuffer).grow with cost 60 as: method(*ByteBuffer) func(int) { if b.writerIndex + n <= len(b.data) { return  }; (*ByteBuffer).growSlow(b, n) }
./buffer.go:85:6: can inline (*ByteBuffer).WriteInt8 with cost 75 as: method(*ByteBuffer) func(int8) { (*ByteBuffer).grow(b, 1); b.data[b.writerIndex] = byte(value); b.writerIndex++ }
./buffer.go:92:6: can inline (*ByteBuffer).WriteUint8 with cost 74 as: method(*ByteBuffer) func(uint8) { (*ByteBuffer).grow(b, 1); b.data[b.writerIndex] = value; b.writerIndex++ }
./buffer.go:211:6: cannot inline (*ByteBuffer).ReadInt8: function too complex: cost 95 exceeds budget 80

[chaokunyang]

add //go:noinline to BufferOutOfBoundError and all similair func in error.go. And would be better to check whole fory go to mark //go:noinline for all cold path

[chaokunyang]

I was wrong, the slow patrh should be annotated with //go:noinline. Please check carefully whether it's other issue. And //go:inline should be removed

[ayush00git]

Let me check once

[ayush00git]

Adding //go:noinline to all error constructors should fix the read path.
But before raising a PR could you adress #3374 as it may cause merge conflicts

[ayush00git]

Hii @chaokunyang
I want to start fixing this bug, pls give #3374 a review.