El problema oculto de Go: abstracciones que ralentizan el código crítico

Este artículo explora un problema fundamental en la optimización de rendimiento en Go: la ausencia de abstracciones de costo cero en las rutas críticas de código (hot paths). El autor, al portar el algoritmo Brotli a Go puro para el proyecto go-brrr, descubrió que las abstracciones idiomáticas del lenguaje (generics, interfaces y closures) impedían al compilador generar código eficiente, mientras que las versiones duplicadas y manuales lograban mejor rendimiento. El problema radica en que Go no puede realizar inline de estas llamadas en múltiples situaciones. Aunque las interfaces permiten intercambio de implementaciones en tiempo de ejecución, el autor enfatiza que incluso los generics utilizan un mecanismo llamado GC Shape Stenciling que no permite realizar inline completo en tiempo de compilación. El artículo presenta un ejemplo concreto con funciones hash, comparando cuatro variantes: concrete, generic, closure e interface. Los benchmarks revelan diferencias significativas: la versión concreta alcanza 378 MiB/s, mientras que generic baja a 320.6 MiB/s (-15.18%), closure a 322 MiB/s (-14.82%) e interface a apenas 274.3 MiB/s (-27.44%). El análisis del assembly generado muestra que la versión concreta tiene instrucciones más simples y directas, mientras las versiones abstractas generan llamadas adicionales y carga de parámetros desde memoria. La solución práctica recomendada es duplicar manualmente las funciones críticas en lugar de usar abstracciones, aceptando el costo de mantenimiento. Esta técnica puede generar 16 o más funciones casi idénticas, como ocurrió en el port de Brotli, aunque para casos con pocas variantes (2-3) no justifica el uso de generación de código.