Go 1.24 usa Swiss Tables para sus mapas: un análisis de bajo nivel
Victoria Metrics disecciona el cambio de implementación en Go 1.24, explicando cómo las tablas suizas afectan al rendimiento y al uso de memoria en tiempo de ejecución.
Go 1.24 ha reemplazado la implementación histórica de sus mapas (map) por un diseño basado en Swiss Tables. Victoria Metrics ha publicado un análisis detallado de este cambio, descomponiendo cómo funciona ahora la estructura de datos en tiempo de ejecución para quienes necesitan entender las implicaciones a nivel de sistema.
El artículo arranca recordando la estructura interna de un mapa en Go. Cuando se ejecuta make(map[string]int), el runtime crea un puntero a una estructura interna runtime.map. Esta estructura contiene campos como used (el número de entradas actuales) y seed (un valor aleatorio que afecta la distribución de las claves). Es fundamental recordar que asignar una variable de mapa a otra solo copia el puntero; ambas variables apuntan a la misma estructura en memoria. Por eso len(m) es una operación O(1): el runtime simplemente lee el campo used sin recorrer la colección.
El cambio sustancial en Go 1.24 reside en cómo se organizan esos datos. La nueva implementación utiliza grupos de ocho entradas como unidad mínima de operación. Cada grupo consiste en un número entero de 64 bits (ctrl) que actúa como palabra de control, y una matriz de ocho ranuras para las claves y valores. Los ocho bytes de ctrl corresponden uno a uno con las ocho ranuras debajo.
El truco de las tablas suizas es que esta palabra de control permite al runtime filtrar rápidamente si una ranura contiene datos válidos sin tocar las claves completas, que suelen ser mucho más grandes y costosas de cargar en memoria caché. Go calcula un hash de la clave usando el seed del mapa y divide ese hash en dos partes: H1 y H2. En sistemas de 64 bits, los 7 bits inferiores del hash (H2) se almacenan en el byte de control correspondiente a la ranura donde se guarda la entrada.
El octavo bit de ese byte de control sirve de bandera. Si es 0, la ranura está ocupada y los otros 7 bits contienen H2 para verificar la coincidencia. Si es 1, la ranura está vacía (0b10000000) o marcada como eliminada (tumba, 0b11111110), sin contener datos reales. Esta distinción es crítica para la lógica de búsqueda: una búsqueda puede detenerse al encontrar una ranura vacía, pero debe continuar si encuentra una tumba, ya que la entrada buscada podría estar más adelante debido a colisiones anteriores.
Victoria Metrics señala que el compilador genera una estructura anónima específica para cada tipo de mapa, lo que permite optimizar el alineamiento. Además, mencionan una propuesta de diseño future con "grupos divididos", separando físicamente las claves de los valores para mejorar la localidad de referencia y eliminar el relleno de alineación, aunque esto está en fase de prueba.
Este cambio de implementación no es solo una curiosidad académica. Las tablas suizas suelen ofrecer búsquedas más rápidas gracias a una mejor utilización de la caché L1, pero introducen una complejidad distinta en la gestión de la memoria y las colisiones. Para desarrolladores que habilitan go124enforce o actualizan a Go 1.24, entender este comportamiento ayuda a diagnosticar cuellos de botella en aplicaciones que manipulan grandes volúmenes de mapas.
