Why lib.Buffer and not bytes.Buffer?

[peterbourgon]

Your lib.Buffer type is very interesting! It has many peculiar capabilities and constraints. What advantages does it have over a pooled bytes.Buffer? e.g.

var bufferPool = sync.Pool{
	New: func() interface{} {
		return &bytes.Buffer{}
	},
}

func GetBuffer() {
	buf := bufferPool.Get().(*bytes.Buffer)
	buf.Reset()
	return buf
}

func PutBuffer(buf *bytes.Buffer) {
	bufferPool.Put(buf)
}

[halturin]

Thanks for the great question.

Yeah, they look very similar, and I really don't remember the reason why I choose to write my own. There might have been some limitations. I will take a look at this code a bit later. Thanks for the good pointing.

[halturin]

The reason for making lib.Buffer was the need to access the undelaying slice without making a call Bytes which is getting expensive for the highload parts of the code. As an example https://github.com/halturin/ergo/blob/master/dist/dist.go#L950

[peterbourgon]

bytes.Buffer.Bytes performs no allocations.

[halturin]

I'm talking about an extra call to get access to the slice. Every call costs performance. For instance, implementing a stackless encoder/decoder improves performance up to 25 times for my case.

[peterbourgon]

Every call costs performance.

Even when it is inlined by the compiler? 🤔

[halturin]

except the inlined, for sure, but there is no pragma to make compiler inline the certain call due to the limitation. there is go:noinline pragma only.

[halturin]

I'm not trying to say that bytes.Buffer doesn't fit my case. Might be it could have been a better idea to use bytes.Buffer, but what if they decide to add something under the hood of Bytes() method which disables inlining? Anyway, lib.Buffer works well atm. Maybe one day I will replace it with the bytes.Buffer.

[halturin]

I finally tried to use bytes.Buffer (branch bytesBuffer)

now I can prove it's more than 3 times slower than my lib.Buffer. Here is the bench results with bytes.Buffer

and here - lib.Buffer

so, its not bad sometimes to make custom solutions :)