This blog post by Russ Cox should help to explain the difference between a struct vs a pointer to a struct, and also the implementation of slices:
https://research.swtch.com/godata There is not a single answer to the question on when to use a struct or a pointer to a struct, and not all answers have to do entirely with optimisation/efficiency... so as in most situations it depends. Please feel free to post back here in case of any further (clarification) questions. On 11 January 2017 at 00:15, Steve Roth <st...@rothskeller.net> wrote: > Suppose you are reading a list of structures, and you do not know in > advance how many there will be. I'm trying to figure out when it's better > to append them to a slice of structures, and when it's better to append > pointers to them to a slice of pointers. It's easy enough to to the math > on how many allocations are done, how much data is copied, etc. But what I > don't know is how to gauge the tradeoff between allocations and data > copies. How much extra data copying is it worth accepting in order to do > fewer allocations? > > A couple of examples. Suppose my structure size is 128 bytes, and it > turns out I read 32 of them. That's 4kB of raw data. > read into []struct{}: 6 allocations totalling 8064 bytes, with 7296 > bytes of data copies > read into []*struct{}: 69 allocations totalling 8568 bytes, with 248 > bytes of pointer copies > So, how does 7kB more data copies balance with 73 more allocations? Is > one clearly better than the other? > > Or suppose a 32 byte structure, and it turns out I read 128 of them. > Again, 4kB of raw data. > read into []struct{}: 8 allocations totalling 8169 bytes, with 7904 > bytes of data copies > read into []*struct{}: 263 allocations totalling 10,200 bytes, with > 1016 bytes of pointer copies > How does 250 more allocations balance with 7kB more copies? > > Of course it would be nice to answer these questions by benchmarking, but > the problem tends to be embedded in highly complex systems that defy > deterministic benchmarking. So all I'm really looking for is the gut feel > of those Go experts who have focused on these sort of optimizations in the > past. Thanks in advance... > > -- > 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. > -- 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.
