Re: [go-nuts] Re: slice of pointer of struct vs slice of struct

No, you are right but then I have made an explicit decision that state is important and mutable so hopefully I would take that into consideration when exposing the data. lör 21 okt. 2017 kl 13:00 skrev Juliusz Chroboczek : > > I have started to use non pointer slices much more as

[go-nuts] Re: slice of pointer of struct vs slice of struct

> I have started to use non pointer slices much more as of late. > Every time I bother measuring it is always faster and it is better for the > GC (usually, caveats apply). So do I. I was just pointing out a caveat that tripped me a couple times. > It also, perhaps naively, feels safer... :)

[go-nuts] Re: slice of pointer of struct vs slice of struct

hmm, suppose I have struct X that have 50 attributes that represent 50 cols in db, struct Y 4 attributes, 4 cols and I have : func FindX() *X {} func FindXs() []*X {} func FindY() *Y {} func FindYs() []*Y {} I don't care about mutable, since this is only a getter func, or should I care?

Re: [go-nuts] Re: slice of pointer of struct vs slice of struct

If I need to mutate elements of an array of by-value structs, I'll usually do this: https://play.golang.org/p/YUFsOkvKQ4 Then for most of the body of the loop, you can use i and t as if you'd ranged over pointers to elements of the slice (no need to explicitly assign to the element). On 20

[go-nuts] Re: slice of pointer of struct vs slice of struct

Which is a good thing: you have to alter the slice explicitly: https://play.golang.org/p/KE2Davl06t When you pass a pointer, you also pass the right to modify the pointee - ownership. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

Re: [go-nuts] Re: slice of pointer of struct vs slice of struct

https://play.golang.org/p/xILWETuAii I have started to use non pointer slices much more as of late. Every time I bother measuring it is always faster and it is better for the GC (usually, caveats apply). It also, perhaps naively, feels safer... :) fre 20 okt. 2017 kl 13:41 skrev Juliusz

[go-nuts] Re: slice of pointer of struct vs slice of struct

>> What size of T affects is appending/inserting/deleting items to/from >> the slice. If one passes around a value of type []T, those operations >> are probably performed on the value. > On the flip side, []*T will be less cache/TLB/GC friendly than > []T, unless T is much larger than a ptr. On

[go-nuts] Re: slice of pointer of struct vs slice of struct

That's a great way to think about it the 'cost' of copying vs passing the address. Thank you. On Friday, 20 October 2017 17:09:49 UTC+10, Feby Tanzil wrote: > > so if I have like 50 attributes then pointer is preferable then > How big is big? I took from >

[go-nuts] Re: slice of pointer of struct vs slice of struct

so if I have like 50 attributes then pointer is preferable then How big is big? I took from https://github.com/golang/go/wiki/CodeReviewComments for receiver, is this applicable for this too? Assume it's equivalent to passing all its elements as arguments to the > method. If that feels too