4 ms·
I like Go a lot, but I often wish we could be more explicit about where allocations are. It’s often important for writing performant code, but instead of having
by throwaway894345 10mo ago
I like Go a lot, but I often wish we could be more explicit about where allocations are. It’s often important for writing performant code, but instead of having semantics we have to check against the stack analyzer which has poor ergonomics and may break at any time.
But yeah, to your point, returning a slice in a GC language is not some exotic thing.
- Yokohiii 10mo agoCan you elaborate on the stack analyzer? All I could figure out was to see runtime.morestack calls that affected the runtime, but as far I remember the caller timings did exclude the cost. Having a clearer view of stack grow rates would be really great.
- throwaway894345 10mo agoI’m not sure what you mean? Are you asking for information about what it is or how to use it?
- Yokohiii 10mo agoI never heard of "stack analyzer" and didn't get meaningful results for it, do you mean escape analysis?
- throwaway894345 10mo agoSorry, yes, I meant “escape analyzer”. I’ve been jet lagged.
- Yokohiii 10mo agoOk no problem. Take a good sleep soon!
- onionisafruit 10mo agoI think I would like a “stackvar” declaration that works the same as “var” except my code won’t compile if escape analysis shows it would wind up on the heap. I say that knowing I’m not a language designer and have never written a compiler. This may be an obviously bad idea to somebody experienced in either of those. I commented elsewhere on this post that I rarely have to think about stacks and heaps when writing Go, so maybe this isn’t my issue to care about either.
- Scaevolus 10mo agoThis could probably be implemented as an expensive comment-driven lint during compilation.
- onionisafruit 10mo agoI don’t think it can be a true linter because it depends on the compiler. But it’s not a bad idea anyway
- Yokohiii 10mo agoEscape analysis sends large allocation to the stack. The information is there.