proposal: strings: add (*Builder).ResetKeepCapacity method

[mateusz834]

Currently the strings.Builder wastes the remaining capacity when (*Builder).Reset is being called, it works just the same way as creating a new empty strings.Builder.

// Reset resets the Builder to be empty.
func (b *Builder) Reset() {
	b.addr = nil
	b.buf = nil
}

Currently it is not possible in a backwards compatibility manner to keep the remaining capacity in the Builder after calling Reset(), because it would require keeping the b.addr pointer, so that it is not possible to copy the Builder.

I propose adding a simple (*Builder).ResetKeepCapacity method with following signature:

// ResetKeepCapacity resets the builder and keeps the remaining
// capacity (b.Cap() - b.Len()) for future use.
func (b *Builder) ResetKeepCapacity() {
	b.buf = b.buf[len(b.buf):]
}

[ianlancetaylor]

This seems like a special purpose operation. When does it come up in practice?

[mateusz834]

When allocating a bunch of small strings when the total size of all strings in more or less known.
This is currently kind of possible using the current API, but not really convenient to use.

func main() {
	var b strings.Builder
	// Case 1: Size known upfront.
	// The size must be known upfront, so that it doesn't grow
	// anymore, because it will unecessary reallocate the previous strings
	// in the builder.
	b.Grow(len("test1") + len("test2"))
	str1 := newStringSizeKnown(&b, []byte("test1"))
	str2 := newStringSizeKnown(&b, []byte("test2"))
	fmt.Println(str1, str2) // test1 test2

	b.Reset()

	// Case 1: Size not known upfront.
	b.Grow(len("test1"))
	str1 = newString(&b, []byte("test1"))
	str2 = newString(&b, []byte("test2"))
	fmt.Println(str1, str2) // test1 test2
}

func newStringSizeKnown(b *strings.Builder, buf []byte) string {
	l := b.Len()
	b.Write(buf)
	return b.String()[l:]
}

func newString(b *strings.Builder, buf []byte) string {
	if b.Cap()-b.Len() < len(buf) {
		b.Reset()
	}
	return newStringSizeKnown(b, buf)
}

[ayang64]

Can you explain what this is trying to achieve? What problem does calling .Reset() cause that this fixes?

[mateusz834]

Can you explain what this is trying to achieve?

Just performance optimizations, reduce a bunch of small string allocations into one bigger memory allocation.

What problem does calling .Reset() cause that this fixes?

With the .Reset() it is currently possible to simulate the .ResetKeepCapacity() method, but the .ResetKeepCapacity() is just simpler and it does not require workarounds as in the examples above (#60768 (comment)).

[ianlancetaylor]

You could keep track of your offsets, call the String method once, and slice the resulting string.

[tjpalmer]

You could keep track of your offsets, call the String method once, and slice the resulting string.

This proposal is important to me.

I just want a long-lived buffer that doesn't require gc and fresh allocation all the time. Allocation slows apps. I can't use the workaround of "just keep appending" because I don't want the old data. I just want a reusable buffer.

I haven't done benchmarking. Just following common wisdom. Presumably I could arrange a benchmark where the difference would be large. And that would apply when app behavior matches benchmark behavior.

[tjpalmer]

Or stated somewhat differently, sometimes the best estimate for buffer capacity is a previous buffer capacity, and I don't want to waste cycles redoing work.