3 ms·

Could you explain further or give links to more information? I'd love to read about old-timey techniques for programming in GCed languages.

jayd16 7y ago
His point is it's not rocket science. Preallocate and pool what you might need, don't call new in your tight loop. Change the GC algorithm to something that never runs unexpectedly. If you're still allocating such that you need GC eventually, manually GC at an appropriate time like a load screen.
- vbarrielle 7y ago
  > Preallocate and pool what you might need, don't call new in your tight loop. This piece of advice is also valid in languages without GC. In C++ it's well known one should avoid allocating memory in tight loops, and it's strongly advised to call e.g. `reserve` on vectors to avoid allocating.
  - p_l 7y ago
    The point is that you lose not only in tight loops. (Tight loop allocating with good GC is actually well known good [1] case, it's deallocation that is PITA). free() as well as malloc() and related have significantly complex algorithms behind them, unless one can simplify base memory management in certain ways - and those ways tend to also allow region-enabled GC to outperform them anyway. [1] Allocating memory in many Garbage Collected systems can be down to one instruction, and if using per-thread heap, it can be atomic add without CAS
p_l 7y ago
A good "keyword" to search is "non-consing code", from lisp lore meaning it doesn't construct (allocate) new space. As sibling comment says, it often involved object caches and static allocations. Interestingly enough, similar rules are necessary with malloc()/free where dynamic allocation is often forbidden for latency critical code (or safety critical one)
p_l 7y ago
Also - I really, really recommend reading the classic GC book ( http://gchandbook.org/ http://gchandbook.org/) and related sources. I stopped complaining too much about developers when I noticed pretty much Noone gets taught how memory management works - either manual or GC

jayd16 7y ago

His point is it's not rocket science. Preallocate and pool what you might need, don't call new in your tight loop. Change the GC algorithm to something that never runs unexpectedly. If you're still allocating such that you need GC eventually, manually GC at an appropriate time like a load screen.

vbarrielle 7y ago
> Preallocate and pool what you might need, don't call new in your tight loop. This piece of advice is also valid in languages without GC. In C++ it's well known one should avoid allocating memory in tight loops, and it's strongly advised to call e.g. `reserve` on vectors to avoid allocating.
- p_l 7y ago
  The point is that you lose not only in tight loops. (Tight loop allocating with good GC is actually well known good [1] case, it's deallocation that is PITA). free() as well as malloc() and related have significantly complex algorithms behind them, unless one can simplify base memory management in certain ways - and those ways tend to also allow region-enabled GC to outperform them anyway. [1] Allocating memory in many Garbage Collected systems can be down to one instruction, and if using per-thread heap, it can be atomic add without CAS

p_l 7y ago

A good "keyword" to search is "non-consing code", from lisp lore meaning it doesn't construct (allocate) new space. As sibling comment says, it often involved object caches and static allocations. Interestingly enough, similar rules are necessary with malloc()/free where dynamic allocation is often forbidden for latency critical code (or safety critical one)

p_l 7y ago

Also - I really, really recommend reading the classic GC book ( http://gchandbook.org/ http://gchandbook.org/) and related sources. I stopped complaining too much about developers when I noticed pretty much Noone gets taught how memory management works - either manual or GC