4 ms·
That's what makes it amusing, but I don't necessarily agree with "Go code that uses 20% of CPU time in GC is usually bad Go code", and I certainly would disagre
by scottlamb 5y ago
That's what makes it amusing, but I don't necessarily agree with "Go code that uses 20% of CPU time in GC is usually bad Go code", and I certainly would disagree if you omitted the word "usually".
Quality code is optimized based on what really matters, and I'm skeptical GC cycles really matter here.
- smarterclayton 5y agoRight now it’s mostly the CRI/kubelet interaction (which polls the container runtime for containers) and metrics scraping generating the garbage. Having an incremental CRI watch (vs poll) has been on the backlog for years, but correctness and features have been more important for most people. Several people were looking at this recently as we were squeezing management pods + system processes onto two dedicated cores for telco/edge real-time use cases (the other tens of cores being reserved for workloads). It’s not that hard to fix, it’s just never been the top priority. Real software has curves.