Hacker News Reader

That is true. Moreover, in general the performance of generic code in Go isn't any better than interface-driven one. Generics are there in Go just for better type safety, and IMO that's sufficient already :)

View on HN

It's all tradeoffs. Fully monomorphized generics tend to blow up compile time.

Full monomorphization can also greatly increase code size and icache pressure. Especially if LTO was not possible.

I haven’t seen icache pressure causing performance degradation in the wild but it is in theory possible.

icache pressure was the bane of my optimization work around 2002. Mostly because it fluctuated unpredictably even from fairly small fairly faraway changes. The system got large enough, with a long enough hot code path that was very hot, that it was almost pointless to benchmark a subsystem in isolation. Simplistic attempts to make any subsystem faster typically made the whole system slower.

In general, whatever subsystem took the cache misses showed up as the slow part, and I owned the very first component in the pipeline... It was fun to compile time disable my component to demonstrate that nothing got faster, though.

Reply on news.ycombinator.com