Why did multiprocessing.Pool slow down a translation-memory updater that ships each record's full context?

## The cost model A pool buys you parallel CPU and charges you serialization. For each task: 1. the parent calls `pickle.dumps` on the callable reference and the arguments, 2. writes the bytes into a pipe, 3. and a worker reads and unpickles them; 4. when the task finishes, the return value makes the same journey back. That is **two serializations and two deserializations per task**, plus the memory to hold the byte strings and the rebuilt objects on both sides. Parallelism pays only when per-task compute is comfortably larger than that fixed cost. ## How the pathology looks A translation-memory updater that fans out per record, passing each record together with the surrounding context it might need, hits the bad end of the curve: a few hundred microseconds of real work wrapped in a payload of tens or hundreds of kilobytes. Because a pool serializes tasks in the parent, the parent process pins one core at full CPU pickling while the workers sit idle waiting for their next task — the classic signature is **a parent at 100% CPU and workers well under it**, with wall-clock time no better than, or worse than, a plain loop. Result payloads cause the mirror image: if each task returns an enriched record rather than a small summary, the parent spends its time unpickling instead. ## Measure, do not guess Two numbers settle the argument. 1. First, `pickle.dumps` a representative argument and time it, and note the byte length; do the same for a representative return value. 2. Second, time the worker function called directly in-process with `time.perf_counter`. If serialization is a meaningful fraction of compute, the boundary is the bottleneck and adding workers cannot help. Payload *distribution* matters as much as the mean: with a shared updater maintained by a four-person team, one record type that carries an enormous segment list will produce an outlier task whose transfer dwarfs everything else, and because tasks flow through a single pipe, that one giant payload stalls the workers queued behind it. An intermittent timeout that never reproduces in a single-process run is very often that outlier, not a deadlock. ## Amortize with bigger tasks The most effective fix is to make each task do **more work per byte sent**. Group records into batches and send a batch per task; the per-task overhead is then divided across the batch, and the number of pipe round trips drops by the same factor. The tuning parameter is the ratio, not the worker count: aim for tasks that run for a noticeable slice of time — tens of milliseconds upward — rather than microseconds. Over-batching costs you load balance at the tail, so the sweet spot is many more batches than workers, but far fewer batches than records. ## Shrink what travels - Send identifiers, offsets or key ranges and let the worker fetch or compute the rest locally. - Return a small verdict rather than a rebuilt object. - Strip fields the worker does not read; a dict with ten keys where the function uses two is 80% waste on every task. - Where the large structure is read-only and shared by all tasks, load it once per worker process at start-up so it never appears in a task payload at all. ## What Python 3.14 changed The default start method on Unix platforms other than macOS is now `forkserver`, not `fork` (macOS and Windows already used `spawn`). - **Under `fork`**, a large structure built in the parent before the pool started was inherited by every child and could be read without ever being sent — an implicit, copy-on-write freebie. - **Under `forkserver`** the children come from a clean server process that only imported modules, so that structure is no longer there and must either be sent explicitly or rebuilt per worker. Code that was quietly fast on Linux can therefore get slower on 3.14 with no source change, and the diagnosis is exactly this payload accounting. ## When the boundary is the wrong tool If the per-record work is I/O-bound, or is dominated by a C extension that releases the GIL around a long computation, threads do the same job with zero serialization because they share the objects outright. Processes earn their overhead only for **CPU-bound pure-Python work with a small, cheap payload**; when the data is big and the work is small, the honest engineering answer is often to keep it in one process and optimise the loop instead.