El coste de un global: una lectura es un acceso a tabla

Existe un consejo repetido en todo código Lua serio: cachear en locales las funciones de la biblioteca estándar que se usan dentro de un bucle. Suele presentarse como folclore, sin justificación y sin medida. La justificación es exacta y se ve en el bytecode: leer una local es leer un registro; leer un global es indexar una tabla con una clave de texto, y math.sqrt son dos indexaciones encadenadas. La medida es más matizada de lo que el folclore sugiere, y saber cuándo la diferencia es relevante —y cuándo cachear te cuesta más de lo que te da— es lo que separa el idioma comprendido del culto a la carga.

Qué ocurre realmente al leer un global

Como veremos en detalle en 9.3, un nombre libre x no es una categoría especial de variable: el compilador lo traduce a _ENV.x, donde _ENV es un upvalue. El bytecode lo deja a la vista. Compila este fichero con luac -l -l:

local function con_global (n) return math.sqrt(n) end

local sqrt = math.sqrt
local function con_local (n) return sqrt(n) end

La primera función emite algo equivalente a GETTABUP 0 0 0 ; _ENV "math" seguido de GETFIELD 0 0 1 ; "sqrt". La segunda emite un solo GETUPVAL. Es decir: donde la versión cacheada hace una lectura directa de un hueco, la versión con global hace dos búsquedas en tabla hash encadenadas, una para math en el entorno y otra para sqrt dentro de math.

Conviene ser justo con la implementación: esas búsquedas están muy optimizadas. Las cadenas cortas en Lua son internalizadas, así que la comparación de claves es de punteros y el hash está precalculado y guardado en el objeto cadena. Un acceso a global no es caro en términos absolutos. Pero sigue siendo un acceso a tabla con todo lo que ello implica: leer el upvalue, comprobar el tipo, calcular la posición en el nodo, seguir la cadena de colisiones y —si la clave no estuviera— consultar la metatabla.

La escritura es simétrica y suele olvidarse. contador = contador + 1 sobre un global emite un GETTABUP y un SETTABUP: dos accesos a tabla por iteración, y el de escritura puede además provocar el rehash de la tabla del entorno si la clave es nueva, o disparar __newindex si hay metatabla. Un acumulador global en un bucle es, con diferencia, el peor patrón medible del lenguaje.

total = 0
for i = 1, 1e6 do total = total + i end   -- GETTABUP + SETTABUP por vuelta

local suma = 0
for i = 1, 1e6 do suma = suma + i end     -- aritmetica sobre registros, sin tablas

Medirlo con honestidad

El error habitual es medir un bucle vacío y extrapolar. Un banco de pruebas mínimamente serio compara el mismo trabajo con la misma cantidad de iteraciones y ejecuta las variantes varias veces alternándolas, para diluir el ruido del sistema y del recolector:

local N = 20e6

local function medir (etiqueta, f)
  collectgarbage()                 -- estado de memoria comparable
  local t0 = os.clock()
  local acc = f(N)
  local dt = os.clock() - t0
  print(string.format("%-12s %.3f s  (acc=%.0f)", etiqueta, dt, acc))
end

local sqrt = math.sqrt             -- la cache

medir("global", function (n)
  local acc = 0
  for i = 1, n do acc = acc + math.sqrt(i) end
  return acc
end)

medir("local", function (n)
  local acc = 0
  for i = 1, n do acc = acc + sqrt(i) end
  return acc
end)

Lo importante no es el número que salga en tu máquina, sino cómo se comporta ese número. La versión cacheada gana siempre, porque hace estrictamente menos trabajo, pero la ventaja relativa se desploma en cuanto el cuerpo del bucle hace algo sustancial. Si el bucle solo lee el nombre, la diferencia es muy visible; si además abre un fichero, construye una tabla o llama a una función que hace un trabajo real, la diferencia se diluye hasta ser irrelevante. Es la ley de Amdahl aplicada al nivel más humilde posible: aceleras un porcentaje minúsculo del programa.

Añade una tercera variante que llame a sqrt a través de una tabla local, como t.sqrt(i), y verás que el coste no era “ser global”: era indexar. Un campo de una tabla propia cuesta prácticamente lo mismo que un global. Lo que abarata la local es haber resuelto la indexación en tiempo de compilación, no la ausencia de la palabra global.

El idioma de cachear la biblioteca estándar

En la cabecera de un módulo de rendimiento crítico verás siempre esta forma, y ahora sabes exactamente qué compra:

-- Cabecera canonica de un modulo caliente
local math, string, table = math, string, table
local sqrt, floor, max = math.sqrt, math.floor, math.max
local format, byte, sub = string.format, string.byte, string.sub
local concat, insert = table.concat, table.insert
local ipairs, pairs, type, select = ipairs, pairs, type, select
local setmetatable, rawget = setmetatable, rawget

Cada línea funciona por la regla de ámbito de 9.1: el nombre de la derecha todavía no está declarado, así que se resuelve al entorno. A partir de ahí, cada uso dentro del módulo es un GETUPVAL desde las funciones internas y un acceso a registro en el propio chunk.

El idioma tiene precio, y es honesto enumerarlo. Fijas el valor en el momento de cargar el módulo: si alguien sustituye después string.format —recarga en caliente, instrumentación, un mock en un test, un perfilador—, tu módulo seguirá usando la función vieja. Si el módulo se ejecuta bajo un entorno alternativo, tampoco lo verá. Consumes upvalues, con un techo de 255 por función. Y ensucias la cabecera con veinte líneas que no dicen nada del dominio del problema. Cachear es congelar, y congelar es renunciar a la indirección que hacía dinámico al programa.

Cuándo importa de verdad

La regla profesional es corta: cachea lo que se usa dentro de un bucle caliente, y no toques nada más. Un módulo de configuración que se ejecuta una vez al arrancar no gana nada medible; un decodificador que procesa un millón de mensajes por segundo sí. Perfila antes, y solo luego escribe la cabecera.

Estos cuatro casos cubren casi todas las decisiones reales:

Hay un matiz de ecosistema que decide el asunto en la práctica. Bajo LuaJIT, el compilador de trazas suele elevar fuera del bucle las lecturas invariantes, con lo que el idioma pierde buena parte de su ventaja en el código que llega a compilarse; en el intérprete y en el código frío la conserva íntegra. Bajo el Lua de referencia —el intérprete puro— la ventaja es siempre real, aunque pequeña en términos absolutos. Y en Neovim el argumento cambia de naturaleza: acceder a vim.api.nvim_buf_set_lines cruza además el puente entre Lua y C, y ahí cachear la referencia sí evita trabajo apreciable en un bucle.

flowchart TD
A[Uso de un nombre en el codigo] --> B[Es local o upvalue]
B -- si --> C[Acceso a un hueco resuelto al compilar]
B -- no --> D[Se traduce a un campo de _ENV]
D --> E[Buscar la clave en la tabla entorno]
E -- encontrada --> F[Valor listo]
E -- ausente --> G[Consultar la metatabla del entorno]
G --> H[Puede ejecutar codigo arbitrario]