4 ms·
Why is spending GB on stack space a bad thing? Ultimately, in a server, you need to store state for each request. Whether that's on the stack or heap, it's stil
by uluyol 4y ago
Why is spending GB on stack space a bad thing? Ultimately, in a server, you need to store state for each request. Whether that's on the stack or heap, it's still memory that necessarily has to be used.
- guenthert 4y agoDespite popular belief, not everything is a (web) server. I can imagine many threads to be appealing in e.g. simulations.
- uluyol 4y agoSure, but my point is that if you want to run 100k-1m things concurrently, you need to store state for them. That has a memory cost no matter what.
- astrange 4y agoI definitely can’t hire anyone in this thread to work on cell phone performance. We fight for 10 KBs of memory and yes, we are still doing this in 2022. Even on a server, you may have TBs of RAM but you don’t have that much L1 cache nor that much memory bandwidth.
- uluyol 4y agoWhy would you need hundreds of thousands or millions of goroutines for a cell phone app/daemon? I would expect the number (and corresponding memory usage) to therefore be low.
- jjnoakes 4y agoIf you need the stack space then there is no difference. The difference arises because if you preallocate all that stack space using worst case stack sizes and don't use most of it, you've wasted lots of memory. Also there is a ton of nuance here like overcommitted pages and large address spaces which mitigate some of those downsides.
- uluyol 4y agoExpect, Go doesn't do that. It grows stacks as you use them and shrinks them if you stop using so much. So the overhead should be limited. FWIW, heap allocations also come with memory overhead.
- jjnoakes 4y agoRight, yes, go does have some nice ways of handling this problem. I was speaking more generally about using that much stack space vs heap space for threads in general - but I should have realized that this specific thread was more about go, and perhaps my comment wasn't as useful in that context.