JIT vs AOT: El motor de ejecución en Dart

Dart utiliza un enfoque híbrido de ejecución para equilibrar la productividad del desarrollador con la eficiencia en producción. Durante el desarrollo, ejecutamos nuestro código mediante el compilador Just-In-Time (JIT), que compila el código fuente a código máquina sobre la marcha mientras la aplicación se está ejecutando. Esto permite una flexibilidad extrema, como el hot reload, ya que el runtime puede re-inyectar código en la memoria. En cambio, para despliegues en producción, utilizamos la compilación Ahead-of-Time (AOT), donde todo el código se traduce a código máquina antes de que el proceso comience.

El diseño responde a una necesidad técnica: el JIT necesita tiempo para analizar el flujo de ejecución y optimizar los “puntos calientes” (hotspots) mediante técnicas de deoptimización y re-optimización (si el perfil de uso cambia, el compilador vuelve a optimizar la función), lo que consume recursos y aumenta la latencia de inicio. El AOT elimina esta carga de trabajo en runtime, ofreciendo un startup casi instantáneo y una latencia de ejecución constante y predecible, aunque sacrifica la capacidad de generar código nuevo o realizar inspección profunda (como el uso de dart:mirrors, que es restringido en AOT para permitir el tree-shaking agresivo).

Para aprovechar estas diferencias, debes usar JIT para el ciclo de desarrollo y pruebas rápidas, y reservar AOT para cualquier entorno donde el rendimiento sea crítico. Si intentas medir el rendimiento real de un algoritmo usando dart run sin considerar el estado del compilador, obtendrás métricas engañosas que no reflejan cómo se comportará el binario final compilado con dart compile exe.

import 'dart:math';

/// Una función de cómputo intensivo para el benchmark.
int procesarDatos(int iteraciones) {
  int acumulador = 0;
  for (int i = 0; i < iteraciones; i++) {
    acumulador += i;
  }
  return acumulador;
}

void main() {
  const int iteraciones = 50_000_000;
  final stopwatch = Stopwatch();

  // Fase de Warm-up: Crucial para el motor JIT.
  // El compilador JIT necesita "calentar" la máquina virtual identificando
  // qué funciones son críticas para optimizarlas mediante profiling.
  print('Calentando el runtime (JIT Warm-up)...');
  for (int i = 0; i < 5; i++) {
    procesarDatos(1000);
  }

  print('Iniciando microbenchmark...');
  
  // Iniciamos el stopwatch para medir la ejecución pura.
  stopwatch.start();
  
  final resultado = procesarDatos(iteraciones);
  
  stopwatch.stop();

  // Usamos el resultado para evitar que el compilador lo considere "código muerto".
  print('Resultado del cálculo: $resultado');
  print('Tiempo de ejecución: ${stopwatch.elapsedMilliseconds} ms');
  print('Tiempo en microsegundos: ${stopwatch.elapsedMicroseconds} μs');
}

En este ejemplo, fíjate en la importancia de la fase de warm-up. Cuando ejecutas este código con dart run (que usa el motor JIT), las primeras llamadas a procesarDatos serán relativamente lentas porque la VM está analizando el bytecode. Tras esas primeras iteraciones, el JIT detecta que la función es un hotspot y la compila a código máquina altamente optimizado. Si no hiciéramos ese bucle inicial de calentamiento, el Stopwatch mediría el tiempo de compilación JIT más el tiempo de ejecución, arruinando la precisión del benchmark.

Hemos utilizado Stopwatch de dart:core en lugar de DateTime.now(). Esto es vital porque DateTime depende del reloj del sistema y tiene una resolución insuficiente para medir operaciones que tardan pocos microsegundos, mientras que Stopwatch utiliza el contador de ciclos de alta resolución de la CPU.

Un detalle crítico es la última línea del print. Al imprimir resultado, nos aseguramos de que el compilador no aplique una optimización de “código muerto” (dead code elimination). Si el resultado de una función no se utiliza para nada que afecte el estado del programa o su salida, un compilador avanzado (especialmente en AOT o tras un JIT muy agresivo) podría decidir que la función entera no es necesaria y eliminar el bucle por completo, haciendo que el benchmark parezca que tarda 0 ms.

El error frecuente

Si intentas optimizar un algoritmo basándote en un microbenchmark mal construido, caerás en una trampa de optimización. Observa este escenario:

// MAL: El compilador puede eliminar todo el bucle
void benchmarkErroneo() {
  final stopwatch = Stopwatch()..start();
  
  for (int i = 0; i < 1000000; i++) {
    // Si el compilador detecta que 'i' no afecta nada externo,
    // la ejecución podría ser optimizada a una instrucción NOP.
    _operacionInutil(10);
  }
  
  print('Tiempo: ${stopwatch.elapsedMicroseconds} μs');
}

void _operacionInutil(int n) {
  // Si esta función no tiene efectos secundarios (side effects),
  // el compilador puede simplemente omitirla.
  int suma = n + n;
}

En el caso anterior, el compilador analiza el flujo y nota que _operacionInutil no modifica ninguna variable global, no realiza I/O y su resultado no se utiliza. En una compilación AOT agresiva, el bucle for podría ser totalmente eliminado del binario final, haciendo que el tiempo de ejecución sea incorrectamente de 0 microsegundos. Siempre asegúrate de que el resultado del cálculo se “escape” del bucle, por ejemplo, mediante un print o asignándolo a una variable global, para forzar al compilador a realizar el trabajo real.

N° 103