cmd/compile: read-only escape analysis and avoiding string -> []byte copies

[bradfitz]

Many functions take a []byte but only read from it.

If the escape analysis code could flag parameters of a function as read-only, then code
which passes in a []byte(string) conversion could be cheaper.

bytes.IndexByte is one example.

For example, http/sniff.go does:

// -------------------
  // Index of the first non-whitespace byte in data.                                                                                               
  firstNonWS := 0
  for ; firstNonWS < len(data) && isWS(data[firstNonWS]); firstNonWS++ {
  }

func isWS(b byte) bool {
        return bytes.IndexByte([]byte("\t\n\x0C\n "), b) != -1
}

// -------------------

But it's faster to avoid re-creating the []byte:

func BenchmarkIndexByteLiteral(b *testing.B) {
        for i := 0; i < b.N; i++ {
        IndexByte([]byte("\t\n\x0C\n "), 'x')
        }
}

func BenchmarkIndexByteVariable(b *testing.B) {
        var whitespace = []byte("\t\n\x0C\n ")
        for i := 0; i < b.N; i++ {
                IndexByte(whitespace, 'x')
        }
}

bytes_test.BenchmarkIndexByteLiteral    20000000           125 ns/op
bytes_test.BenchmarkIndexByteVariable   100000000           25.4 ns/op

Related is issue #2204.

[gopherbot]

Comment 1 by jp@webmaster.ms:

It seem to be much easier to add the possibility of zerocopish taking string slices from
byte slices/arrays.
As far I understand, string slices are actually readonly and cap()'less byte slices:
http://research.swtch.com/2009/11/go-data-structures.html

[bradfitz]

Comment 2:

zerocopish?

[rsc]

Comment 3:

Can you be more specific?
Examples of programs that you think should be
handled specially would be a good way to do that.

[rsc]

Comment 4:

Owner changed to @rsc.

Status changed to Accepted.

[lvdlvd]

Comment 5:

Labels changed: added compilerbug, performance.

[rsc]

Comment 6:

Labels changed: added priority-later.

[rsc]

Comment 8:

Labels changed: added go1.1maybe.

[bradfitz]

Comment 9:

I run into this often, but I should start listing examples.
In goprotobuf, text.go calls writeString with both a string and a []byte converted to a
string:
// writeAny writes an arbitrary field.
func writeAny(w *textWriter, v reflect.Value, props *Properties) {
        v = reflect.Indirect(v)
        // We don't attempt to serialise every possible value type; only those
        // that can occur in protocol buffers, plus a few extra that were easy.
        switch v.Kind() {
        case reflect.Slice:
                // Should only be a []byte; repeated fields are handled in writeStruct.
                writeString(w, string(v.Interface().([]byte)))
        case reflect.String:
                writeString(w, v.String())
Note that the function writeString reallly just wants a read-only slice of bytes:
func writeString(w *textWriter, s string) {
        w.WriteByte('"')
        // Loop over the bytes, not the runes.
        for i := 0; i < len(s); i++ {
                // Divergence from C++: we don't escape apostrophes.
                // There's no need to escape them, and the C++ parser
                // copes with a naked apostrophe.
                switch c := s[i]; c {
                case '\n':
                        w.Write([]byte{'\\', 'n'})
                case '\r':
                        w.Write([]byte{'\\', 'r'})
                case '\t':
                        w.Write([]byte{'\\', 't'})
                case '"':
                        w.Write([]byte{'\\', '"'})
                case '\\':
                        w.Write([]byte{'\\', '\\'})
                default:
                        if isprint(c) {
                                w.WriteByte(c)
                        } else {
                                fmt.Fprintf(w, "\\%03o", c)
                        }
                }
        }
        w.WriteByte('"')
}
It doesn't matter that it's frozen (like a string), nor writable (like a []byte).  But
Go lacks that type, so if instead it'd be nice to write writeAny with a []byte parameter
and invert the switch above to be like:
        switch v.Kind() {
        case reflect.Slice:
                // Should only be a []byte; repeated fields are handled in writeStruct.
                writeString(w, v.Interface().([]byte))
        case reflect.String:
                writeString(w, []byte(v.String())) // no copy!
Where the []byte(v.String()) just makes a slice header pointing in to the string's
memory, since the compiler can verify that writeAny never mutates its slice.

[bradfitz]

Comment 10:

See patch and CL description at http://golang.org/cl/6850067 for the opposite
but very related case: strconv.ParseUint, ParseBool, etc take a string but calling code
has a []byte.

[robpike]

Comment 11:

Labels changed: removed go1.1maybe.

[rsc]

Comment 12:

[The time for maybe has passed.]

[bradfitz]

Comment 13:

People who like this bug also like issue #3512 (cmd/gc: optimized map[string] lookup from
[]byte key)

[dvyukov]

Comment 14:

FWIW
var m map[string]int
var b []byte
_ = m[string(b)]
case must be radically simpler to implement than general read-only analysis.
It's peephole optimization, when the compiler sees such code it can generate hacky
string object using the []byte pointer.
Another example would be len(string(b)), but this seems useless.

[bradfitz]

Comment 15:

Yes. That's why they're separate bugs.
I want issue #3512 first, because it's easy.

[bradfitz]

Comment 16:

Labels changed: added garbage.

[rsc]

Comment 18:

Labels changed: added priority-someday, removed priority-later.

[rsc]

Comment 19:

Labels changed: added repo-main.

[rsc]

Comment 20:

Adding Release=None to all Priority=Someday bugs.

Labels changed: added release-none.

[mattn]

IMO, I think that it's difficult to provide way for converting types since that bytes might be on stack not heap allocator.

var s string
// s = "hello" // This should be crash because "hello" might be on stack.
s = string([]byte("hello"))
header := (*reflect.StringHeader)(unsafe.Pointer(&s))
bytesheader := &reflect.SliceHeader{
	Data: header.Data,
	Len:  header.Len,
	Cap:  header.Len,
}
b := *(*[]byte)(unsafe.Pointer(bytesheader))
b[0] = 0x48

[jfcg]

In any case, this issue is for the conversion the other way, string -> []byte.

Simpler example (tested with Go 1.17.8 / 1.18):
pkg.go

package pkg

// ToLower converts ascii string s to lower-case
func ToLower(s string) string {
	if s == "" {
		return ""
	}
	buf := make([]byte, len(s))

	for i := 0; i < len(s); i++ {
		c := s[i]
		if 'A' <= c && c <= 'Z' {
			c |= 32
		}
		buf[i] = c
	}
	return string(buf)
}

pkg_test.go

package pkg

import "testing"

func BenchmarkToLower(b *testing.B) {
	str := "SomE StrInG"
	want := "some string"
	var res string

	for i := 0; i < b.N; i++ {
		res = ToLower(str)
	}
	if res != want {
		b.Fatal("ToLower error")
	}
}

go test -v -bench ToLower -benchmem -count=3 prints

BenchmarkToLower-4      18710726                66.86 ns/op           32 B/op          2 allocs/op
BenchmarkToLower-4      17420910                65.57 ns/op           32 B/op          2 allocs/op
BenchmarkToLower-4      17085405                63.16 ns/op           32 B/op          2 allocs/op

There is a redundant allocation & copy in return string(buf). It looks too trivial to me that I am surprised Go compiler cannot handle this.

[gopherbot]

Change https://go.dev/cl/520259 mentions this issue: cmd/compile/internal/escape: optimize indirect closure calls

[gopherbot]

Change https://go.dev/cl/520395 mentions this issue: cmd/compile: enable zero-copy string->[]byte conversions

[dmitshur]

CL 520395 that resolved this issue was reverted in CL 520596, so reopening.

[gopherbot]

Change https://go.dev/cl/520599 mentions this issue: cmd/compile: restore zero-copy string->[]byte optimization

[gopherbot]

Change https://go.dev/cl/520600 mentions this issue: cmd/compile: enable -d=zerocopy by default

[jfcg]

Hi,
These changes address redundant copying for string <--> []byte conversions both ways, right?

[mdempsky]

@jfcg No, at this time only string->[]byte.

[cespare]

I believe that #43752 discusses at least some of the []byte->string cases.

(@mdempsky it's exciting that this 4-digit issue is so close to being solved!)

[zigo101]

BTW, should the old optimization for for range []byte(aString) be unified into the new optimization? Maybe it has been?

[gopherbot]

Change https://go.dev/cl/584118 mentions this issue: encoding/hex: don't overallocate memory in DecodeString

[zigo101]

So now we can take string element addresses without unsafe.StringData:

package main

func main() {
	s := "go"
	
	// All true.
	println(StringData(s) == StringData(s))
	println(*StringData(s) == 'g')
	println(*StringData(s[1:]) == 'o')
}

func StringData(s string) *byte {
	if len(s) == 0 {
		return nil
	}
	return &[]byte(s)[0]
}

;D