Un Dense Arena Interner es una estructura que convierte cadenas y tipos en identificadores enteros únicos en el momento de su creación, de modo que el resto de las fases del compilador —analizador sintáctico, comprobador de tipos y optimizador— dejen de pagar el coste de comparar texto repetidamente y operen únicamente sobre índices contiguos y punteros estables. El artículo, firmado por Aiko Schurmann, recorre la motivación técnica de esta decisión.
El autor parte del cuello de botella clásico del enfoque ingenuo: un analizador léxico que compara cada identificador con una lista de palabras reservadas mediante strcmp incurre en un coste O(N·L), donde N es el número de palabras clave y L la longitud del identificador. Pasar a una tabla hash reduce la búsqueda a O(L), pero el hash se recalcula en cada fase posterior. Con internado, ese coste se paga una sola vez durante el lexado: cada cadena única queda almacenada una única vez en un Arena Allocator, que garantiza direcciones de memoria estables y asignación O(1) bumping-pointer, y recibe un identificador denso (0, 1, 2…). Las fases siguientes pueden entonces comparar y despachar en O(1) usando solo el índice entero o un único cmp de punteros.
El texto detalla las dos abstracciones centrales —Slice, referencia no propietaria a una secuencia de bytes, e InternResult, manejador canónico que une la Slice del Arena con la entrada densa— y explica por qué la combinación HashMap + Arena es la pieza que hace viable el patrón. Como contrapartida, el autor señala la naturaleza no liberable del Arena: resulta adecuada para compiladores por lotes que descartan toda la memoria al terminar, pero puede provocar crecimiento descontrolado si se reusara dentro de un servidor LSP de larga vida, donde los archivos cambian con frecuencia. La conclusión operativa es que internar deslocaliza el coste de las cadenas hacia una única fase y deja el resto del pipeline prácticamente constante.