Parallel script is slower than serial
Documentation: Microsoft Learn
Work the problem
Concurrency adds overhead
Fictional case: A serial run processes ten tiny in-memory items in less time than a parallel run. Both return the same values.
Reasoning notebook
Record the evidence that supports your answer and the check you would run next. Your notes stay in this browser — nothing is uploaded.
Why it happens
Every runspace pays a startup cost and has to import whatever modules the work requires, which for small units of work exceeds anything saved. Arguments and results are serialized crossing the boundary, so passing large objects adds further overhead. When the bottleneck is one remote service or a single disk, extra workers simply queue against it.
Check this first
What to look for
Runspace and scheduling overhead can exceed the useful work. Measure realistic workloads before choosing concurrency.
Working through it
- Time both versions with Measure-Command over the same input so the comparison reflects reality.
- Count the work items and estimate per-item duration, since parallelism rarely pays below a few hundred milliseconds each.
- Lower the throttle limit and measure again, because too many runspaces on a small machine can be slower than a few.
- Move module imports and expensive setup outside the parallel block wherever the construct allows it.
- Establish whether the target is a shared resource, in which case batching rather than concurrency is the fix.
Avoiding it next time
Verify the repair: Compare timings, output equivalence and error handling under realistic I/O and throttling conditions.