Diagnosing Slow parfor Loops in MATLAB Parallel Computing Toolbox

The problem and what to check first

A MATLAB parfor loop that runs slower than the equivalent serial for loop, or that leaves CPU cores idle, is usually not a MATLAB bug. It is typically a data-movement, load-balance, worker-count, or I/O problem. The useful takeaway: measure the serial baseline and the parallel overhead before changing code, then apply the fix that matches the measured bottleneck.

parfor executes loop iterations on MATLAB workers, separate MATLAB computational engines managed by a parallel pool. Variables split across iterations are called sliced variables; variables sent whole to each worker are broadcast variables. Oversubscription means starting more workers than physical CPU cores, which can cause context-switching and slower throughput.

Recognizable condition and likely causes

Condition	Likely cause	Where it shows up
parfor slower than serial for	Excessive data transfer to workers	Profiler: high parfor overhead
Some workers idle, others at 100%	Load imbalance across iterations	OS task manager or MATLAB monitor
Low CPU use despite many cores	Too few workers for available cores	gcp.NumWorkers versus core count
Stalls or license errors during loop	Shared file I/O or licensing conflicts	MATLAB Command Window errors

Ordered diagnostic checks

1. 1. Establish a serial baseline with tic/toc

   Run the equivalent serial for loop in the MATLAB Command Window and record elapsed time:

   tic
   for i = 1:N
       result(i) = myFunction(data(:,i));
   end
   serialTime = toc;

   Run the same iterations with parfor and record parallelTime. If parallelTime is not meaningfully lower, proceed to the next check. Placeholder N is the iteration count; myFunction is your computation. No special permissions are required. Risk: none beyond normal MATLAB use.

2. 2. Profile the parfor overhead

   In the Command Window:

   profile on
   parfor i = 1:N
       result(i) = myFunction(data(:,i));
   end
   profile off
   profile viewer

   Open the Profiler report and look for time spent inside parfor setup and worker communication rather than inside myFunction. Profiling adds its own overhead, so use it for comparison, not absolute timing.

3. 3. Compare worker count to physical cores

   Check the current pool:

   pool = gcp;
   disp(pool.NumWorkers)

   Open your operating system's task manager or activity monitor and note the number of physical CPU cores. If NumWorkers is far below the core count, the pool may be underutilized. If it is above the physical core count, you risk oversubscription. Adjust the pool before the loop:

   delete(gcp)
   parpool('local', 4) % placeholder: set to your physical core count or lower

   Run this in the Command Window. No special permissions are required. Risk: setting workers above physical cores can reduce throughput through context switching.

4. 4. Estimate sliced-variable data transfer

   Inspect variables used inside the parfor loop. A sliced variable such as data(:,i) is divided among workers, but MATLAB still transfers the required portions to each worker and returns results. Large sliced inputs or outputs dominate runtime when the per-iteration computation is small. Estimate size in the Command Window:

   whos data result

   If the transferred data is large relative to the computation, data transfer is likely the bottleneck.

5. 5. Identify non-parallelizable or unsafe calls

   Review function calls inside the loop. Code that writes to the same file, updates a shared variable outside slicing rules, or calls a MEX function that is not thread-safe can serialize workers or produce nondeterministic results. Look for fprintf to a single log file, assignments to a global variable, or load/save inside the loop body.

Fixes tied to each finding

Data transfer dominates

• Reduce sliced-variable size: pass only the columns or rows needed for each iteration.
• Prefer read-only broadcast variables: data that is identical for every iteration is sent once to each worker instead of being partitioned per iteration.
• Avoid returning large arrays from every iteration; accumulate results outside the loop or write to worker-local files.

Load imbalance

• Make iteration work more uniform, or order iterations so heavy and light tasks alternate.
• Ensure the iteration count is much larger than the worker count so workers can pick up remaining tasks.

Too few workers

• Start a local pool sized to physical cores: parpool('local', N) where N is your physical core count, not thread count.
• Do not exceed physical cores; oversubscription can lower overall throughput.

I/O or licensing conflicts

• Move file open, write, and close operations outside the parfor loop.
• Give each worker a unique filename if workers must write during the loop.
• If repeated license checkout errors appear, contact your license administrator before further tuning.

Non-parallelizable calls

• Replace element-wise work inside the loop with vectorized MATLAB operations where possible.
• Compile computationally intensive MEX code only if it is thread-safe; otherwise keep it serial or isolate it.

Verify the result

Run a benchmark script before and after changes. Compare tic/toc elapsed times and CPU usage in your operating system's task manager. Confirm the Profiler shows less time in parfor overhead and balanced worker utilization.

Most importantly, verify correctness. Run the serial and parallel versions and compare outputs:

isequal(serialResult, parallelResult)

A result of 1 means the outputs match. Any discrepancy indicates a remaining parallelization issue, such as an unsliced shared variable or unsafe MEX call. Note that floating-point reductions may differ in the last bits because of operation order; treat tiny numerical differences as expected, not corruption.

Limitations

• parfor has fixed overhead for starting and communicating with workers. Very short iterations may never beat a serial loop.
• This guide covers local workers on one machine. Cluster or cloud profiles require different diagnostics.
• Worker count is not the same as maxNumCompThreads, which controls multithreaded computation inside a single MATLAB session, not the number of parallel pool workers.

Escalation criteria

Escalate to MathWorks Support if, after applying the fixes above, any of the following are true:

• The parfor loop still shows more than 50% overhead compared with the serial baseline.
• Workers fail to start or the pool becomes unresponsive.
• Repeated license checkout errors appear during parallel execution.

When contacting support, include the Profiler report, the output of ver, and your operating system's CPU/core count.

Rollback

Changing the pool size or editing the loop changes MATLAB state. To roll back, delete the pool and restore the default:

delete(gcp)
parpool

If you edited code, restore the previous version from your file backup or version control before rerunning benchmarks.