Interesting tidbit from https://medium.com/@val_deleplace/go-code-refactoring-the-23x-performance-hunt-156746b522f7 … — “The execution time is now dominated by the allocation and the garbage collection of small objects (e.g. the Message struct), which make sense because memory management operations are known to be relatively slow.”
-
-
Wait, Go *doesn't*? I feel like the more I learn about Go the more confused I get about why it's meant to be so great.
-
No, Go doesn’t. The language designers have for some reason decided they don’t want generational GC, and defend this choice. :(
- 2 more replies
New conversation -
-
-
I dug in to this benchmark a little. The live set is about two KB, so generations per se don't buy much. ~1% of runtime is GC proper. Bump allocation would help (perf record says 40% spent allocating). Hard to tell what costs are from free lists vs concurrent synchronization.
-
Yeah, to be clear I think that the bump allocation in TLABs would be the biggest win from having generational GC.
- 2 more replies
New conversation -
-
-
That’s GC 101, right
Not sure why anyone would do it differently. -
Go designers, sadly, are digging their heels in the ground regarding their decision not to do generational GC. :(
- 14 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.