Trying Worker Threads for a Job That Didn't Need Them

A script that generates reading-time estimates for every post was taking a noticeable fraction of a second, and I decided — without measuring anything first — that the fix was worker threads. Parallelism sounds like a free win. It is not free.

What I actually built

The idea was to split the post list across a worker pool, count words in parallel, and merge the results. It worked, in the sense that it ran and produced correct numbers.

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);
  });
}

What it actually did to the build

It made the whole step forty percent slower. Spinning up a worker thread has fixed overhead — a new V8 isolate, a message channel — and the actual work per post, counting a few hundred words and dividing by 200, takes microseconds. I’d paid a real, measurable cost to parallelize a job so small that a single synchronous loop finishes before a worker thread would even finish starting up.

What I should have done first

Profile before optimizing is advice I already knew and apparently didn’t believe applied to me this time. A five-minute console.time around the original synchronous version would have shown the whole step took eleven milliseconds — not a target for parallelism, a rounding error in a build that takes several seconds regardless. I reverted the worker pool and left the original loop alone. It was already fine. The lesson wasn’t about worker threads being bad; it’s that I reached for a tool built to solve a problem I hadn’t confirmed I had.