On Wednesday, February 22, 2017 at 6:53:53 AM UTC+8, Caleb Spare wrote: > > I have a program that uses unsafe in order to coerce some slices to > strings for use as map keys. (Avoiding these allocations ends up being > an important performance optimization to this program.) > > Here's some example code that shows what I'm doing: > > https://play.golang.org/p/Yye1Riv0Jj
Looks ok, but sliceToStringUnsafe in m[sliceToStringUnsafe(v)] = 1 is not essential, for gc compiler has already made the same optimization for you. Just use m[string(v)] = 1 is ok. > > > Does this seem OK? I've tried to make sure I understand how all the > unsafe codes fits into the blessed idioms at > https://golang.org/pkg/unsafe/#Pointer. The part I'm most curious > about is the indicated line: > > sh.Data = (*reflect.StringHeader)(unsafe.Pointer(&s)).Data // <--- > > This is a double-application of rule 6: it's a conversion *from* a > reflect.StringHeader's Data field *to* a reflect.SliceHeader's Data > field, through an unsafe.Pointer and uintptr. > > This code has been working for a long time and appears to continue to > work, but I've been re-reviewing all my unsafe usage after reading the > conversation at https://github.com/golang/go/issues/19168. > > Thanks for any insights. > Caleb > > P.S. In this particular case, I'm planning on replacing the map with a > custom hashtable (since it's very specialized I can do better than a > built-in map type) and that will eliminate the unsafe code. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
