4 ms·
Having explicit pointers gives you more control over allocation. As you mention, Go is a GC language, and there are no guarantees of whether allocation will occ
by echlebek 9y ago
Having explicit pointers gives you more control over allocation. As you mention, Go is a GC language, and there are no guarantees of whether allocation will occur on the stack or the heap. But generally, non-pointer values will be stack-allocated. This reduces pressure on the GC, since the values are just discarded along with the stack frame on return.
For this reason, it's usually considered good form to pass values to functions instead of pointers, even if the values are larger. This allows the compiler to prove through escape analysis that the arguments don't need to be heap-allocated. In some cases pointers can be proven not to escape, but in a limited set of circumstances.
Having explicit pointers also resolves type system awkwardness between simple and complex data types. Consider Java, which is also a pass-by-value language, but has "reference" types, except for int, float, etc. So everything is a reference except this bag of simple data types, effectively creating a 2-tiered type system. Java has dealt with this by implementing boxing and unboxing rules for int/Integer and friends, which is fine, but adds complexity.
Finally, one of my personal favourite features about having a complex data type that is a value instead of a pointer or reference is that you can use structs and arrays as map keys.
- agentgt 9y agoAs I mentioned in another similar comment I think this is the key point for me why it makes sense: > Having explicit pointers also resolves type system awkwardness between simple and complex data types. That is it appears to be worth it to have explicit pointers for data structures (and the manipulation of those data structures) and probably more so with a concurrent language. That is when the programmer sees things that don't have pointers they can make some generally assumptions (the struct or whatever is generally immutable).
- kristianp 9y agoSo how big does my struct need to be before its more efficient to pass a pointer to it to a function?
- Matt3o12_ 9y agoI've often wondered this myself. Perhaps the right answer would be to benchmark and/or use the profiler. On the other handy, I have never really had a situation where I had to pass a strict that was really big (more then 1MB). Most of the time, big data structures are actually just slices, which use pointers to point to the memory address of the underlying array (as far as I understand). So having sich big struct is rather unusual. Maybe it is possible to do with strings, though it would depend on how are strings implemented in go (I would guess they are just slices as well). Furthermore, having big strings 1<x<50 MB) is rather unusual unless the strings can also become really big (1GB in which case you should not probably pass-by-reference or even better, buffer the string because arbitrary length strings can easily cause ram problems).
- echlebek 9y agoIn Go, strings are internally a header that contains a length and a pointer. The bytes of the string itself are heap allocated.
- echlebek 9y agoWell, it depends whether the time spent copying the bytes for the function invocation is less than the time spent garbage-collecting objects that are passed as pointers, and then following those pointers. So as you can imagine, it's highly variable depending on the lifecycle of those objects, how frequently the function is being called, and probably a bunch of other factors like how big your CPU cache is. And then there is the cost of pointer indirection, which can cause cache misses. I don't think there's really a rule of thumb here. Writing benchmarks, and observing the results is about the best you can do.
- deleted 9y ago[deleted]