I find that people coming to Go from C++ tend to use pointers everywhere so as to avoid copying of structs. Once they get a bit more experience, they tend to use fewer pointers, and are happier to pass structs around. Removing the "make everything a pointer" optimisation makes the code simpler, and often actually makes it run faster as fewer values escape the heap. Allocation tends to dominate Go runtime, so it is worth doing a bit more copying in order to get a bit less allocations.
On Saturday, 5 June 2021 at 22:34:09 UTC+1 axel.wa...@googlemail.com wrote: > I would add that because the dynamic type of an interface value is not > known at compile time, a variable of interface type really can't (in > general) have a specific size. > If a function has an interface parameter, it must be possible to pass a > value of *any* size to it. So even aside from what the current > implementation does - any Go compiler must, in general¹, consider > interfaces to be pretty-much-pointers. > > "in general" because a compiler can, of course, determine that in a > certain scenario the value doesn't have to be packed and pass it as-is. > This is an optimization sometimes called "devirtualization". But in the > general case, a compiler can't prove that (e.g. the dynamic value in an > interface could be determined by a random number generator), so it will > always be an optimization and the default always has to be a form of boxing > into a constantly sized shape. > > All of this is a good indication, from first principles, that you don't > have to worry about the size of the dynamic value when passing it. > > What's more, in general you should trust the author of the package you are > using to give you a reasonable implementation of an interface. You > shouldn't worry what the dynamic type and value in an interface is, unless > you have very good reason to care. In this case, unless you notice that > your code is very slow if you don't use a pointer (that would be "a very > good reason to care"), you shouldn't optimize it. And if you notice, you > should open a bug against that package :) Though as established, you won't. > > On Sat, Jun 5, 2021 at 11:18 PM Ian Lance Taylor <ia...@golang.org> wrote: > >> On Sat, Jun 5, 2021 at 2:15 PM Joshua <joshua.o...@gmail.com> wrote: >> > >> > My question is general, but for ease of communicating I'll use the >> specific example I ran into. >> > >> > I'm very new and for my first project I'm working with the bleve >> library [https://pkg.go.dev/github.com/blevesearch/bleve]. >> > >> > One function I need, "Open", returns an interface, "Index". >> > >> > I'd like to write my own function to act on this interface, and given >> that I have no idea what the dynamic value of the interface is, my first >> instinct is to rather pass a pointer to the returned interface into my >> function. >> > >> > However, I see lots of calls of "If you're using pointers to interfaces >> a lot, you probably don't understand them". >> > >> > Well, what am I not understanding? >> > My worry is that I have no idea what dynamic type is lurking within the >> interface, if it's a pointer to a struct, then I obviously don't mind >> passing it into my function. >> > >> > However if it is in fact a humungous 1GB struct, then I really really >> don't want to be copying that around willy-nilly. >> > >> > Is there a way in general to avoid this, without looking at the library >> source code to see what the actual concrete type is? >> >> In the current implementations a value of interface type is always a >> pair of pointers. Even if the value of interface type happens to >> refer to a 1GB struct, copying the interface value, including passing >> it to a function or returning it from a function, always just copies >> two pointers. >> >> Ian >> >> -- >> 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...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUuv_qrrG8%3DdCQZv0%2BrKbnbW60XdOCwjp8M3EdOCxCNkw%40mail.gmail.com >> . >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2fc297cf-0068-4547-8316-e0512169c91fn%40googlegroups.com.
