Probando worker threads para un trabajo que no los necesitaba

Un script que genera estimaciones de tiempo de lectura para cada entrada estaba tomando una fracción de segundo notable, y decidí —sin medir nada primero— que el arreglo eran worker threads. El paralelismo suena como una ganancia gratis. No es gratis.

Lo que realmente construí

La idea era dividir la lista de entradas entre un pool de workers, contar palabras en paralelo, y combinar los resultados. Funcionó, en el sentido de que corría y producía números correctos.

const { Worker } = require('node:worker_threads');

function countInWorker(text) {
  return new Promise((resolve) => {
    const worker = new Worker('./count-worker.js', { workerData: text });
    worker.on('message', resolve);
  });
}

Lo que realmente le hizo al build

Hizo el paso entero cuarenta por ciento más lento. Levantar un worker thread tiene un costo fijo —un nuevo isolate de V8, un canal de mensajes— y el trabajo real por entrada, contar unas pocas cientos de palabras y dividir por 200, toma microsegundos. Pagué un costo real y medible por paralelizar un trabajo tan chico que un solo loop síncrono termina antes de que un worker thread siquiera termine de arrancar.

Lo que debería haber hecho primero

Perfilar antes de optimizar es un consejo que ya conocía y aparentemente no creía que se me aplicara esta vez. Un console.time de cinco minutos alrededor de la versión síncrona original habría mostrado que el paso entero tomaba once milisegundos —no un objetivo para paralelismo, un error de redondeo en un build que de todos modos tarda varios segundos. Revertí el pool de workers y dejé el loop original tranquilo. Ya estaba bien. La lección no era que los worker threads sean malos; es que recurrí a una herramienta hecha para resolver un problema que no había confirmado tener.