3 ms·
Whether a pointer is bad for performance in this case seems hard to tell a priori. There are also performance advantages if Optional packs nicely.
by morelisp 5y ago
Whether a pointer is bad for performance in this case seems hard to tell a priori. There are also performance advantages if Optional packs nicely.
- frenchie4111 5y agoAgreed on performance being in the air. Tbh, I like the non-pointer option because using a pointer was causing the implementation to feel a bit weird. This cleans up a bit of the handling that was annoying (for example in the old implementation Make(&"something") didn't work because you can't reference a constant without first making a variable.
- Mawr 5y agoIt is just an assumption on my part, I figure that the cost of pointer chasing is generally going to outweigh any disadvantages. It can also help enable optimizations, for example slices and maps that do not contain pointers do not get scanned by the GC ([1]). [1]: https://github.com/golang/go/commit/85e7bee19f9f26dfca414b1e9054e429c448b14f https://github.com/golang/go/commit/85e7bee19f9f26dfca414b1e...
- stingraycharles 5y agoI fully agree with your approach. The important thing is that the user now has the choice to use a pointer or not: they can always use a pointer to the optional if they want to use pointers. Pointers to pointers are generally something you try to avoid if possible.
- morelisp 5y ago> the user now has the choice to use a pointer or not But any benefits of the packing are gone whether I make a pointer or not. And either way, no nested pointers are involved. We’re not taking pointers to options in either case.