| ▲ | carb 4 days ago | |
Why have you had to avoid the heap? Performance concerns? | ||
| ▲ | malkia 4 days ago | parent | next [-] | |
For me, avoiding heap, or rather avoiding gc came when I was working (at work) on backend and web server using Java, and there was default rule for our code that if gc takes more than 1% (I don't remember the exact value) then the server gets restarted. Coming (back then) from C/C++ gamedev - I was puzzled, then I understood the mantra - it's better for the process to die fast, instead of being pegged by GC and not answering to the client. Then we started looking what made it use GC so much. I guess it might be similar to Go - in the past I've seen some projects using a "baloon" - to circumvent Go's GC heuristic - e.g. if you blow this dummy baloon that takes half of your memory GC might not kick so much... Something like this... Then again obviously bad solution long term | ||
| ▲ | ignoramous 4 days ago | parent | prev [-] | |
Garbage Collection. The content of the stack is (always?) known at compile time; it can also be thrown away wholesale when the function is done, making allocations on the stack relatively cheaper. These FOSDEM talks by Bryan Boreham & Sümer Cip talk about it a bit: - Optimising performance through reducing memory allocations (2018), https://archive.fosdem.org/2018/schedule/event/faster/ - Writing GC-Friendly [Go] code (2025), https://archive.fosdem.org/2025/schedule/event/fosdem-2025-5... Speaking of GC, Go 1.26 will default to a newer one viz. Green Tea: https://go.dev/blog/greenteagc | ||