[Triage] SFT formatting map spawns up to 8 worker processes for a trivial string-join and gives no measured gain (CR-A03-095) #82

Needs triage. Reviewers disagreed on this finding, so it is not counted in the backlog. Decide whether it is a real defect: if yes, set severity and wave; if not, close it with the reason.

CR-A03-095 — SFT formatting map spawns up to 8 worker processes for a trivial string-join and gives no measured gain

severity Info · confidence disputed · single reviewer · reproduced end to end

What happens. _format_sft_dataset runs .map(processor, batched=True, num_proc=min(os.cpu_count() or 1, 8)) (data.py:681-687) for every split. The processor is pure-Python string concatenation; tokenisation happens later in TRL. Measured on this 18-core macOS host (datasets 5.0, caching disabled, JSONL of messages rows): N=200: 0.30 s with 8 procs vs 0.17 s with 1; N=20k: 0.48 s vs 0.28 s; N=200k: 1.15 s vs 1.34 s. Break-even is about 200k rows, and the absolute difference is under a second. The cost is a fixed per-split pool start/dill pickling of the closure (a larger relative cost on spawn platforms, where each worker re-imports forgelm). On Linux (fork) the cost is likely lower; not measured.

Where.

• forgelm/data.py:681-687

Recommended fix. Use num_proc=None below a row threshold (say 100k) or drop it. Gain: 0.1-0.2 s per split plus fewer pool failures; negligible at the documented scale.

_{Found by the October 2026 ForgeLM code and documentation review against commit cab2947. Code links point at that commit; line numbers may have moved since. Finding IDs (CR-…, DOC-…, TECH-…) are stable references for this backlog.}