V8 y motores JavaScript: hidden classes, JIT, optimización y antipatrones de rendimiento

V8 es el motor JavaScript que impulsa tanto Node.js como Chrome, y su arquitectura interna tiene implicaciones directas en el rendimiento del código que escribimos. Comprender cómo funciona el pipeline de compilación, qué son las hidden classes y el inline caching permite escribir código que el JIT puede optimizar eficientemente, y evitar los antipatrones que provocan desoptimizaciones.

El pipeline de compilación de V8

V8 no interpreta ni compila estáticamente: usa un enfoque mixto que evoluciona en tiempo de ejecución según la frecuencia de uso del código:

// Fase 1: INTERPRETACIÓN (Ignition)
// El código fuente se parsea y compila a bytecode.
// La primera ejecución usa el intérprete Ignition.
// Es rápido de iniciar pero más lento por instrucción.

// Fase 2: COMPILACIÓN JIT (TurboFan)
// Las funciones "calientes" (ejecutadas muchas veces) se optimizan.
// TurboFan genera código máquina nativo muy rápido.

// Fase 3: DESOPTIMIZACIÓN
// Si las suposiciones que hizo TurboFan resultan incorrectas,
// vuelve al bytecode de Ignition y puede reoptimizar más tarde.

function sumarNumeros(a, b) {
  return a + b;
}

// Estas llamadas permiten a V8 especializarse para números
for (let i = 0; i < 10_000; i++) {
  sumarNumeros(i, i + 1); // V8 optimiza asumiendo argumentos numéricos
}

// Ahora una llamada con string provoca DESOPTIMIZACIÓN
sumarNumeros('hola', ' mundo'); // V8 descarta la versión optimizada

Hidden classes: el secreto detrás de la velocidad

V8 crea internamente una "clase oculta" (hidden class o shape) para cada objeto según las propiedades que tiene y en qué orden se añadieron. Los objetos con la misma hidden class pueden acceder a sus propiedades con un offset fijo, igual que los campos de una struct en C:

// BUENA PRÁCTICA: inicializar todas las propiedades en el constructor
// Todos los objetos comparten la misma hidden class
class Punto {
  constructor(x, y) {
    this.x = x; // Hidden class C0 ? C1 (añade .x)
    this.y = y; // Hidden class C1 ? C2 (añade .y)
  }
}

const p1 = new Punto(1, 2);
const p2 = new Punto(3, 4);
// p1 y p2 comparten la hidden class C2 ? acceso rápido

// MAL: añadir propiedades en orden diferente ? hidden classes distintas
const a = {};
a.x = 1; a.y = 2; // Hidden class: x, y

const b = {};
b.y = 2; b.x = 1; // Hidden class diferente: y, x

// a y b NO comparten hidden class aunque tengan las mismas propiedades
// ? el acceso a propiedades es más lento

// PEOR: añadir propiedades dinámicamente según condiciones
function crearConfig(esAdmin) {
  const config = { nombre: 'app', version: '1.0' };
  if (esAdmin) {
    config.secreto = 'admin123'; // Hidden class diferente para admin y no-admin
  }
  return config;
}

// MEJOR: inicializar con null si la propiedad es opcional
function crearConfigBien(esAdmin) {
  return {
    nombre: 'app',
    version: '1.0',
    secreto: esAdmin ? 'admin123' : null, // Misma hidden class siempre
  };
}

Inline caching (IC)

El inline caching es la técnica por la que V8 recuerda el tipo de los argumentos en una llamada concreta y puede saltar directamente a la versión optimizada. Hay tres estados:

// MONOMORFICO (1 tipo) — el caso más rápido
function calcularArea(figura) {
  return figura.ancho * figura.alto;
}

const rect = { ancho: 10, alto: 5 };
for (let i = 0; i < 10_000; i++) {
  calcularArea(rect); // Siempre el mismo tipo ? inline cache monomorfico
}

// POLIMORFICO (2-4 tipos) — más lento, pero V8 puede manejarlo
class Rectangulo { constructor(a, b) { this.ancho = a; this.alto = b; } }
class Cuadrado { constructor(l) { this.ancho = l; this.alto = l; } }

const formas = [new Rectangulo(4, 5), new Cuadrado(3)];
formas.forEach(f => calcularArea(f)); // 2 hidden classes ? polimórfico

// MEGAMORFICO (5+ tipos) — V8 abandona el IC, peor rendimiento
// Si calcularArea recibe objetos de 5 estructuras distintas,
// V8 no puede mantener el inline cache eficientemente

Benchmark: medir antes de optimizar

// Usar performance.now() para microbenchmarks
function benchmark(nombre, fn, iteraciones = 1_000_000) {
  // Warm-up para que V8 optimice
  for (let i = 0; i < 1000; i++) fn(i);

  const inicio = performance.now();
  for (let i = 0; i < iteraciones; i++) fn(i);
  const fin = performance.now();

  console.log(`${nombre}: ${(fin - inicio).toFixed(2)}ms para ${iteraciones} iteraciones`);
}

// Comparar acceso con hidden class compartida vs no compartida
const objBueno = { x: 0, y: 0, z: 0 };

function accesoBueno(obj) { return obj.x + obj.y + obj.z; }

benchmark('acceso optimizado', () => accesoBueno(objBueno));

Antipatrones que desoptimiza V8

// 1. Argumentos de tipo mixto en funciones calientes
function procesar(valor) {
  return valor * 2; // Muy rápido si siempre number
}
procesar(42);     // OK
procesar('texto'); // Desoptimiza la versión numérica

// 2. delete de propiedades — cambia la hidden class
const config = { a: 1, b: 2, c: 3 };
delete config.b; // Crea una nueva hidden class — evitar en rutas calientes
// Mejor: config.b = undefined;

// 3. Arrays con tipos mixtos (backing store cambia de tipo)
const numeros = [1, 2, 3, 4];      // SMI_ELEMENTS — muy rápido
numeros.push(3.14);                  // ? DOUBLE_ELEMENTS — conversión
numeros.push('texto');               // ? GENERIC_ELEMENTS — lento
// Mantener arrays homogéneos: siempre enteros, siempre doubles, etc.

// 4. Funciones muy grandes — difíciles de optimizar para TurboFan
// Extraer funciones pequeñas es mejor para el JIT y para el mantenimiento

// 5. try/catch en rutas calientes (en versiones antiguas de V8)
// Versiones modernas lo manejan mejor, pero en Node 18+ ya no es un problema significativo

Herramientas de profiling en Node.js

// Ejecutar con el profiler de V8
// node --prof mi-script.js
// node --prof-process isolate-*.log > profile.txt

// O usar el CPU profiler programático
const v8Profiler = require('v8-profiler-next');

v8Profiler.startProfiling('MiPerfil', true);

// ... código a perfilar ...

const perfil = v8Profiler.stopProfiling('MiPerfil');
perfil.export((error, resultado) => {
  require('fs').writeFileSync('perfil.cpuprofile', resultado);
  // Abrir el .cpuprofile en Chrome DevTools ? Performance
});

// Ver deoptimizaciones en tiempo real:
// node --trace-deopt mi-script.js
// node --trace-opt mi-script.js

La regla de oro con la optimización de V8 es: escribir código predecible, con tipos consistentes, objetos inicializados de forma uniforme y funciones pequeñas. V8 es extraordinariamente bueno optimizando código JavaScript idiomático. Los antipatrones de rendimiento suelen surgir cuando el código hace cosas que impiden a V8 hacer suposiciones estables sobre los tipos de datos.