bytes: make Buffer.String avoid copy if possible

[bradfitz]

Years ago I filed #6714, hoping that it would one day be possible to construct a string efficiently without wasted allocations.

I hereby propose that we stop waiting and just do it explicitly with a new type in a new internal package.

package builder // import "internal/builder"

// String is like a bytes.Buffer but never allows its internal
// byte slice to escape. The zero value is usable.
type String struct {
     // ...
}

func (s *String) Len() int { ... }
func (s *String) Grow(n int) { ... }
func (s *String) WriteByte(b byte) { ... }
func (s *String) WriteString(s string) { ... }
func (s *String) Write(b []byte) { ... }
func (s *String) String() string { ... }

The (*String).String method would use unsafe to make a string header out of an internal []byte slice header.

The Write methods could even recycle old too-small []byte backing arrays as they grow.

There would be no Reset or Bytes or Truncate or Read methods. Nothing that could mutate the []byte once it was unsafely converted to a string.

The implementation would have to take care to use a new []byte backing array on any resize after an unsafe string was constructed.

[minux]

This package doesn't sound too magical to require compiler/runtime helps and it will be generally useful. Perhaps add it to the strings package instead? one possible implementation: // invariant: with all grow methods, we must make sure len(bytes) < cap(bytes) // When String is called, we freeze the byte slice by reslicing it so that len == cap // and then just return the String itself as a string header using unsafe (this relying // on the fact that the first two fields in a slice header is the same as a string header.. type String struct { bytes []byte }

[minux]

We can even make compiler do the transform for us (like Java's StringBuilder). e.g. transform all variable string concatenations like: s := fmt.Sprintf("A%d", n) + "ABC" into: var sb builder.String fmt.Fprintf(&sb, "A%d", n) sb.WriteString("ABC") s := sb.String()

[cznic]

+1 on this as I'm actually using something quite similar already.

[minux]

I realized that we don't need to maintain any invariant: the underlying []byte is append-only, so we can convert that to a string at any time without worrying whether the later updates could modify the string's underlying buffer.

[robpike]

bytes.Buffer already does no allocations up to 64 bytes, but then to make a string of course there is one allocation.

It could be smarter.

I would prefer we find a way not to add more ways to create strings. There are several already.

[luna-duclos]

I would love a publicly available API for this rather than an internal package

[seh]

Java has had this same problem since its start: There is no way for any caller outside the java.lang package to create a String that doesn't copy the backing character array. As noted here, even Go's bytes.Buffer makes a copy before exposing the accumulated string, in fear that subsequent operations against the bytes.Buffer would change the would-be-shared backing array.

It would nice to have a method on bytes.Buffer (or something similar) like Take, which returns a string using the backing array—without copying it—and then invalidates or resets the Buffer, so that subsequent operations against it would either panic or use a fresh backing array.

As the original description here notes,

The implementation would have to take care to use a new []byte backing array on any resize after an unsafe string was constructed.

A method like Take makes that need explicit, though it does impose unnecessary cost when the last operation against the buffer is to take a string from it.

[dmitshur]

a new internal package

What's the reason and effect of internal being involved in this proposal?

Edit: The effect is that it would prevent code outside of GOROOT to import the package.

[rsc]

I have a number of questions and concerns.

• Why? This proposal gives no justification or intended use cases, making it very hard to evaluate as an engineering decision.
• Why only internal? Is there some compelling reason that the standard library is special and needs this magic capability but code outside the standard library does not? It's hard to believe people won't just copy it into their own projects, which is not something we want to encourage.
• This is an unsafe operation and will be overused and used incorrectly.
• I still believe the compiler can do significantly better. My recent reading about other systems with immutability (in particular, Midori) suggests that it's actually not too hard to identify the string(buf) conversions in which buf is not retained elsewhere and not used after the conversion; those can reuse buf for the storage when appropriate.

Doing this right in the compiler seems tractable, it avoids additional API, it avoids internal-only API, and it avoids forcing programmers to make unsafe decisions. It seems better on every axis than introducing a new package. But maybe there is some consideration I am missing.

[bradfitz]

@rsc,

Why? This proposal gives no justification or intended use cases, making it very hard to evaluate as an engineering decision.

See #6714 and the bugs referencing it. The justification is to reduce allocations and thus make the GC run less often and thus reduce CPU usage.

Why only internal? Is there some compelling reason that the standard library is special and needs this magic capability but code outside the standard library does not? It's hard to believe people won't just copy it into their own projects, which is not something we want to encourage.

Only because I figured it would be less controversial to start internal and see if we like the API first. We could export it later.

This is an unsafe operation and will be overused and used incorrectly.

No, the API would be designed such that it's impossible to use incorrectly or unsafely. It would only use unsafe itself, like reflect does, even though reflect is a safe part of the language. I tried to convey that in the top post.

I still believe the compiler can do significantly better. My recent reading about other systems with immutability (in particular, Midori) suggests that it's actually not too hard to identify the string(buf) conversions in which buf is not retained elsewhere and not used after the conversion; those can reuse buf for the storage when appropriate.

Significantly? In any case, that is #6714, filed in 2013. We can keep waiting, of course.

[bradfitz]

@robpike, @seh,

bytes.Buffer already does no allocations up to 64 bytes, but then to make a string of course there is one allocation.

Yes, but bytes.Buffer exposes its innards via (*Buffer).Bytes() etc. It would need to keep track more state to use unsafe safely.

A method like Take makes that need explicit, though it does impose unnecessary cost when the last operation against the buffer is to take a string from it.

If we did that, we'd need all the safety bookkeeping in that type anyway, so at that point I'd rather just make (*bytes.Buffer).String be the Take function, so there's no new API surface.

But only if we decide that bytes.Buffer wants to get into this business and use unsafe.