If your MATLAB code is taking longer to run than you expect, the first thing I would avoid is blindly rewriting it.

MATLAB is built for numerical and technical computing, so it already does a lot of heavy lifting behind the scenes. When a program is slow, the problem is often more specific: an array is growing inside a loop, the same calculation is being repeated thousands of times, too much data is being moved around, or the algorithm itself is doing more work than necessary.

The good news is that you can usually find these bottlenecks with a few practical techniques. In this guide, I'll show you how I approach MATLAB performance optimization, starting with simple changes and moving into options such as parallel processing and GPU computing.

Start by Finding Out What Is Actually Slow

Before changing anything, measure the code.

This sounds obvious, but it is one of the easiest steps to skip. I've seen developers spend time optimizing a loop only to discover later that most of the runtime was actually coming from file I/O or a completely different function.

MATLAB gives you several useful tools for this. The timeit function is a good choice when you want to benchmark a function, while tic and toc are convenient for measuring a particular section of code. MATLAB's Profiler goes a step further by showing where execution time is being spent.

For example:

f = @() myPricingFunction(S, K, T, r, sigma);

baselineTime = timeit(f);

You can then profile the function:

profile on

myPricingFunction(S, K, T, r, sigma);

profile viewer

The important part is establishing a baseline. Once you know how long the original code takes, you have something objective to compare against.

Don't worry about making every line as fast as possible. If one function accounts for 80% of the runtime and another accounts for 1%, the first one deserves your attention.

Preallocate Arrays Before Filling Them

One of the easiest MATLAB optimization mistakes to fix is allowing arrays to grow repeatedly inside a loop.

For example:

for i = 1:N

results(i) = expensiveCalculation(i);

end

If MATLAB has to keep expanding results as the loop progresses, it may need to repeatedly allocate and reorganize memory.

If you already know the required size, allocate the array first:

results = zeros(1, N);

for i = 1:N

results(i) = expensiveCalculation(i);

end

The same idea applies to matrices:

A = zeros(rows, cols);

for j = 1:cols

A(:,j) = calculateColumn(j);

end

This small change can make a noticeable difference when a loop runs many thousands or millions of times.

I particularly recommend checking for this in simulation code. Monte Carlo models, optimization routines, and large numerical experiments can generate very large arrays, so unnecessary memory allocation can quickly become expensive.

Don't Automatically Replace Every Loop With Vectorized Code

Vectorization is one of the best-known ways to improve MATLAB performance, and for good reason.

MATLAB is designed around arrays, so an operation that can be performed on an entire vector or matrix is often better expressed that way.

Instead of:

for i = 1:length(x)

y(i) = sin(x(i));

end

you can simply write:

y = sin(x);

Likewise:

y = x.^2;

z = a .* b;

q = a ./ b;

These operations make it clear that you want element-by-element calculations.

However, I wouldn't turn "avoid loops" into a hard rule.

Modern MATLAB handles many loops efficiently, especially when the arrays have been preallocated and the loop body is sensible. A clear loop can also be easier to maintain than an overly complicated vectorized expression.

So rather than asking, "Can I eliminate this loop?" I prefer asking, "Which implementation performs better for my actual workload?"

Benchmark both when the difference matters.

Stop Repeating Work You Don't Need

Another common source of wasted processing is calculating the same thing again and again.

Consider this example:

for i = 1:N

discountFactor = exp(-r*T);

results(i) = price(i) * discountFactor;

end

discountFactor does not depend on i, so recalculating it on every iteration serves no purpose.

Move it outside the loop:

discountFactor = exp(-r*T);

for i = 1:N

results(i) = price(i) * discountFactor;

end

The saving from one calculation might be tiny. The saving from avoiding millions of repeated calculations is not.

When reviewing slow MATLAB code, I look for anything that is constant during a loop, including:

• Matrix factorizations
• Conversion calculations
• File reads
• Lookup tables
• Constants
• Repeated function calls with identical inputs
• Intermediate values that never change

This is often a much easier optimization than trying to rewrite the entire program.

Use MATLAB's Built-In Numerical Operations

MATLAB's built-in numerical functions have been heavily optimized, so there is often little reason to recreate functionality manually.

A classic example is solving a system of equations.

Instead of:

x = inv(A) * b;

use:

x = A \ b;

The second approach directly asks MATLAB to solve the system Ax = b.

The same principle applies to many other numerical tasks. Before writing a custom implementation, check whether MATLAB already provides a function that performs the operation you need.

This can improve performance while also making the code easier for someone else to understand.

There is another advantage: MATLAB's built-in functions can take advantage of optimized numerical libraries and low-level implementations that would be difficult to reproduce efficiently in ordinary MATLAB code.

Pay Attention to Memory, Not Just CPU Time

A program can be CPU-bound, memory-bound, or affected by the amount of data being moved around.

This becomes increasingly important as your datasets get larger.

Suppose a calculation creates several large temporary arrays:

largeTemporary = complicatedCalculation(data);

result = process(largeTemporary);

Once largeTemporary is no longer required, releasing it can help reduce memory pressure:

clear largeTemporary

You can inspect your current variables with:

whos

I would also question whether every calculation really needs double precision. In some applications, single precision may be sufficient and can reduce memory requirements.

That decision should be made carefully, though. In scientific computing and financial modelling, changing precision can affect numerical accuracy. Always compare the optimized version against a trusted reference calculation before accepting the change.

Use Sparse Matrices When Most Values Are Zero

A large matrix containing mostly zeros does not necessarily need to be stored as a conventional dense matrix.

MATLAB supports sparse matrices specifically for this type of problem.

For example:

A = sparse(i, j, values, m, n);

Instead of storing every element, MATLAB's sparse representation focuses on the nonzero entries.

This can be extremely useful for large systems arising in areas such as finite-element analysis, graph problems, optimization, and numerical simulations.

There is an important qualification here: sparse matrices are not automatically faster.

If your matrix is reasonably dense, forcing it into sparse form may actually make things worse. The structure of the problem matters.

For large sparse problems, it can also be worth preallocating sparse storage with spalloc rather than repeatedly expanding the matrix.

Use parfor When the Work Can Be Split Up

Once you've improved the basic MATLAB implementation, parallel computing may be worth considering.

The key question is whether individual iterations can run independently.

For example:

for i = 1:N

results(i) = runSimulation(i);

end

If each simulation is independent, the loop may be suitable for:

parfor i = 1:N

results(i) = runSimulation(i);

end

This allows MATLAB's Parallel Computing Toolbox to distribute iterations across workers.

Monte Carlo calculations are a particularly obvious example because individual simulation paths are often independent.

But don't assume parfor will automatically make everything faster.

There is overhead involved in starting workers and moving data. If each iteration takes only a tiny amount of time, that overhead can outweigh the benefit of parallel execution.

For that reason, I would benchmark the serial and parallel versions using the same inputs rather than assuming the parallel version is better.

GPU Computing Can Help With the Right Workload

If the calculations are highly parallel and involve large numerical datasets, GPU acceleration may be another option.

MATLAB supports GPU computing through gpuArray and the Parallel Computing Toolbox.

A simple example looks like this:

X = gpuArray(rand(5000));

Y = X.^2;

result = gather(Y);

The important thing to understand is that GPU acceleration isn't simply a matter of putting a calculation on a graphics card.

Moving data between the CPU and GPU takes time. If your program constantly sends small arrays to the GPU, performs a tiny calculation, and immediately brings the results back, you may gain little or nothing.

The better approach is usually to keep large datasets on the GPU for as long as practical and perform enough computation there to justify the transfer.

For GPU workloads, use appropriate benchmarking tools such as gputimeit rather than relying on a naive tic/toc measurement.

Don't Optimize Hardware Before Optimizing the Algorithm

This is probably the most important point in the entire process.

It is tempting to think that slow MATLAB code needs a faster processor, more CPU cores, or a GPU.

Sometimes it does.

But hardware cannot compensate for an inefficient algorithm indefinitely.

Imagine two implementations of the same calculation. If one performs millions of unnecessary operations while the other uses a more efficient numerical method, putting the first implementation on a faster machine may only postpone the problem.

My usual order is:

1. Measure the existing implementation.
2. Profile it.
3. Remove unnecessary calculations.
4. Preallocate arrays.
5. Improve inefficient numerical operations.
6. Reduce memory usage and data movement.
7. Benchmark the revised version.
8. Consider parallel or GPU computing if the workload still justifies it.

That sequence keeps optimization focused on the actual problem.

Consider MATLAB Coder for Deployment

There are situations where improving the MATLAB implementation itself isn't enough.

If MATLAB code needs to become part of a production system or a performance-sensitive application, MATLAB Coder can generate C or C++ code from supported MATLAB code.

Compiled code can open up additional optimization opportunities, including compiler optimizations and optimized numerical libraries.

This is more involved than simply changing a few MATLAB statements, though. Code-generation compatibility, data types, array sizes, supported functions, and memory behaviour all need to be considered.

I would therefore treat MATLAB Coder as a later-stage option rather than the first solution to a slow script.

And when the MATLAB code is supporting something as demanding as quantitative finance, derivatives modelling, or large-scale simulation, performance work often needs to consider the numerical method as well as the MATLAB implementation. In those cases, specialist derivatives pricing options services can be useful when the challenge goes beyond basic MATLAB syntax and involves the underlying pricing model, numerical methods, or computational architecture.

A Simple Workflow for Optimizing MATLAB Code

When I need to improve an existing MATLAB program, I find a structured workflow much more useful than collecting random optimization tricks.

1. Create a reliable benchmark

Use timeit, tic/toc, or another appropriate measurement method.

Run the same workload consistently so that your results are comparable.

2. Profile the application

Find out where MATLAB is actually spending its time.

Don't guess.

3. Fix the obvious problems

Look for dynamically growing arrays, repeated calculations, unnecessary file operations, excessive temporary data, and inefficient numerical expressions.

4. Look at the algorithm

Ask whether the calculation itself can be simplified.

An algorithmic improvement can be far more significant than changing the syntax of a single line.

5. Re-test accuracy

This is especially important for engineering, scientific, and financial applications.

A faster result isn't useful if it is no longer numerically trustworthy.

6. Benchmark again

Compare the new implementation with your original baseline.

Keep changes that produce a meaningful improvement and don't introduce unnecessary complexity.

7. Scale only when necessary

If the optimized serial version is still too slow, then investigate parallel computing, GPU acceleration, or code generation.

The Best MATLAB Optimization Is the One You Can Measure

There isn't one magic trick that makes every MATLAB program faster.

For some applications, preallocating arrays may solve the main problem. For others, the real improvement might come from changing an algorithm, using sparse matrices, moving independent simulations to parfor, or keeping a large numerical workload on the GPU.

The important thing is to avoid optimizing based on assumptions.

Measure first. Find the bottleneck. Make one meaningful change. Test the result.

That approach may sound less exciting than throwing a complicated optimization technique at the problem, but it is much more reliable.

Ultimately, good MATLAB optimization isn't about making code clever. It's about making it do the same useful work with less unnecessary computation, less memory overhead, and less wasted time.