4 ms·
The notion of stack vs heap allocation isn't something that even exists in the language. Users are expected to not worry about it... until, of course, until you
by athorax 1y ago
The notion of stack vs heap allocation isn't something that even exists in the language. Users are expected to not worry about it... until, of course, until you're optimizing performance and you need to worry about it.
This is one of the best and worst aspects with Go. Anyone can write pretty performant code without having to understand the underlying memory model. If you get to the point where you are trying to optimize at this level, the benefits of using a more approachable language start to fall apart and you spend more time chasing implementation details.
- Ygg2 1y agoI think same applies to any GC language. Ride is fun until GC starts either taking too much time, too much memory or taking too much of CPU.
- nu11ptr 1y agoIn general, it is a win, since it lets you code faster and 80-90% the performance doesn't matter. Over time, you learn generally what leads to heap allocs and what doesn't. In rare hot spot, using -m will show you the allocations and you can optimize.
- athorax 1y agoI would generally agree. It's good enough performance for most applications. For those that it isn't fast enough for (even with optimizations like these), it still allows for rapid prototyping to arrive at that conclusion.
- Thaxll 1y agoAt least you have the tools to understand where things get allocated.