Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Reducing allocations isn't about the speed of allocations. Yes, allocating with a generational GC is very fast, as is stack allocation.

Reducing allocations is about reducing the time needed to perform garbage collection.

That time is zero for stack based allocation and non-zero for any heap based allocation. Stack based allocation or memory pools etc. reduce the pressure on the GC. Having more GC runs means not only time spent in the GC, with generational GCs it also can mean premature aging of objects - while collecting the nursery is very fast, collecting older generations has a larger cost.

So, with any GC and language, the less heap allocations, the faster your code will run. (Unless of course, your program code gets much worse by trying to avoid heap allocations).



To nitpick, the time for stack allocation isn't zero. Stack objects still have to be traced.

But yes, there is some benefit to reducing allocation. The biggest benefit to escape analysis doesn't really have anything to do with allocation at all. Rather it's that promoting objects to the stack enables SROA, which unlocks a lot more optimizations.

This article wasn't about that, though. These were short-lived benchmarks that are dominated by throughput. In those types of benchmarks, allocation speed matters much more than mark and sweep time. So, the best way to optimize for these sorts of workloads is to add generational garbage collection with bump allocation in the nursery.


I didn't claim that the cost for stack allocation was zero. I claimed that the cost for stack deallocation is zero. Thats where the stack wins against garbage collectors.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: