Introduction

For large matrices in MATLAB, the fastest code is usually the code that lets MATLAB call its optimized linear algebra libraries directly. Performance problems usually come from memory pressure, unnecessary copies, or choosing a data representation that does not match the structure of the data.

Start with Native Matrix Multiplication

If your matrices fit comfortably in memory, the best baseline is simply C = A * B. MATLAB routes that operation through highly optimized BLAS and LAPACK routines, often using multithreaded native code underneath. Replacing it with hand-written for loops is almost always slower.

1m = 4000;
2n = 3000;
3p = 2000;
4
5A = rand(m, n, 'single');
6B = rand(n, p, 'single');
7
8C = A * B;
9size(C)

Even this basic example already shows two important ideas: use built-in operators, and choose data types deliberately. If single precision is acceptable for your problem, it cuts memory use in half compared with double precision.

Memory Is Often the Real Bottleneck

Very large matrix multiplication is not only about arithmetic cost. It is also about whether A, B, and C can exist in memory at the same time. A dense 10000 x 10000 matrix in double precision is roughly 800 MB by itself. Three matrices of that size can push you into swapping or out-of-memory errors before multiplication becomes the main problem.

If memory is tight, check whether the data is truly dense. If most entries are zero, use sparse matrices.

1A = sprand(20000, 20000, 0.0005);
2B = sprand(20000, 5000, 0.0005);
3
4C = A * B;
5whos A B C

Sparse multiplication can reduce both memory use and runtime dramatically when the structure supports it.

Use Block Multiplication for Huge Dense Data

When matrices are too large to process comfortably in one shot, multiply them in blocks. The idea is to keep only part of the data in active memory while accumulating the result.

1function C = blockMultiply(A, B, blockSize)
2    [m, n] = size(A);
3    [n2, p] = size(B);
4    assert(n == n2, 'Inner dimensions must agree');
5
6    C = zeros(m, p, 'like', A);
7
8    for k = 1:blockSize:n
9        kEnd = min(k + blockSize - 1, n);
10        C = C + A(:, k:kEnd) * B(k:kEnd, :);
11    end
12end

A = rand(3000, 8000);
B = rand(8000, 2000);
C = blockMultiply(A, B, 500);

Block multiplication does not change the mathematical result. It changes how much intermediate data is live at once, which can be the difference between a successful run and a crash.

GPU Acceleration Can Help

If you have Parallel Computing Toolbox and a suitable GPU, moving the multiplication to the GPU can provide a large speedup for dense workloads.

1A = gpuArray(rand(5000, 5000, 'single'));
2B = gpuArray(rand(5000, 5000, 'single'));
3
4C = A * B;
5C = gather(C);

GPU acceleration is not automatic for every workload. The transfer cost between CPU memory and GPU memory matters, so it works best when the matrices are large enough to justify that movement.

Measure Before You Optimize Further

Do not guess which version is faster. Measure it on the machine that actually runs the job.

f1 = @() A * B;
time_builtin = timeit(f1)

Once you have a baseline, compare alternatives such as sparse storage, single precision, block size changes, or GPU execution. MATLAB performance tuning is usually empirical.

Common Pitfalls

• Replacing A * B with manual loops usually throws away MATLAB’s best optimizations.
• Using double precision by default can waste memory when single precision is enough.
• Treating sparse data as dense can make both runtime and memory usage much worse.
• Ignoring memory layout leads to out-of-memory failures long before the arithmetic is finished.
• Moving small matrices to the GPU can be slower than staying on the CPU because transfer cost dominates.

Summary

• Start with MATLAB’s built-in * operator before trying custom code.
• For large dense matrices, memory limits often matter as much as raw compute speed.
• Use sparse matrices when the data contains many zeros.
• Use block multiplication when the full dense operation is too large for comfortable memory usage.
• Benchmark changes with timeit so optimization decisions are based on measurements.