An interesting GC-related find earlier this week: it can help a lot to allocate in large chunks when you can: https://plus.google.com/+ChandraSekarS0/posts/MNM

An interesting GC-related find earlier this week: it can help a lot to allocate in large chunks when you can: https://plus.google.com/+ChandraSekarS0/posts/MNMWAXr63qz https://plus.google.com/+ChandraSekarS0/posts/MNMWAXr63qz Note that the entire chunk stays "alive" while any element in it is reachable, so this only works when arena allocation would in a non-GC'd language, i.e., when you're going to free the entire chunk at once (or in those rare cases you never need it reclaimed, e.g., 'cause it's a big fixed-size pool that you'll recycle forever). To my surprise, allocating big chunks performed better than a Pool or manual recycling in this case. My best guess, and the author's, is that fewer allocations meant less space on memory-allocator bookkeeping (so fewer GCs) and less time spent sweeping in each GC. If anyone's more aware of the guts of the runtime than I am and can confirm or disconfirm or elaborate, I'm curious.