Memory leak in complex griddedInterpolant

Hello,

I am experiencing a memory leak when loading griddedInterpolant with complex vales multiple times. I have prepared a test script reproducing this issue:

%% complex griddedInterpolant memory leak test

A = complex(rand(5e3),rand(5e3));
% A = rand(5e3);

A = griddedInterpolant(A);

save testfile A;
clear A;

user = memory;
m0 = user.MemUsedMATLAB;

for i = 1:100
    
    load testfile A;
    clear A;

    user = memory;
    disp(user.MemUsedMATLAB-m0);
    m0 = user.MemUsedMATLAB;

end

In each step, Matlab displays the increase in user memory from the previous step, which in this case is around 400 MB (likely the size of the complex double array 5e3^2*8*2). After several steps Matlab runs out of memory.

The memory leak does not occur when uncommenting line

A = rand(5e3);

which indicates that the issue occurs with complex numbers only.

Similarly when commenting line

A = griddedInterpolant(A);

there is no memory leak either, so the issue is limited to griddedInterpolant and not just any complex array.

Is this really a bug, or did I miss anything here?

[Bruno Luong]

I confirm it seems like the leak is real.

[dpb]

@Ondrej, you should submit the subject script to official TMW support as bug report (you can just mail <[e-mail]>). Answers isn't an official support platform so something posted here won't necessarily be seen by those who need to know inside Mathworks.

[Ondrej]

Thanks for the responses, I have been a couple of days offline, but I have just submitted the bug report to the TMW support.

[Benji]

I have also seen this issue and can confirm the code above also shows a memory leak on MacOS. I also believe, though cannot show simple code to demonstrate this, that using a griddedInterpolant as a property in a handle object shows similar memory leak issues. For large data grids, this problem becomes dramatic, often causing MATLAB to crash.

[Andreas Akselsen]

@Benji, I can confirm that you are right.

I further identified the issue as arrising between v. 2023b (no issue) and 2024a (issue).

Here's a quick example where the two loops run about the same on 2023b while the second runs orders of magnitude slower on say 2025a.

clear all
nx = 1000000; dx = .01; nRepeat = 1000; 
nIP = 1150;
xIP = rand(nIP,1)*dx*nx;

data = rand([nx,1],'like',1i);  % issue disappears instead using real numbers
gi = griddedInterpolant((0:nx-1)'*dx,data);
sc = StructClass();
sc.gi = gi;

tic
for i = 1:nRepeat,  b = gi(xIP); end
fprintf('relTime: %.4fms\n',toc*1000/nRepeat)

tic
for i = 1:nRepeat,  b = sc.gi(xIP); end
fprintf('relTime: %.4fms\n',toc*1000/nRepeat)

with

classdef StructClass % < handle or not
    properties
        gi
    end
end

Answer 1

[Amish]

Hi Ondrej,

As I can see, this issue is reproducible and has been identified as a potential bug. There was a similar issue occurring in the R2019b. This might get fixed in the future releases.

One of the workarounds is to split A into real and imaginary parts and interpolate those separately:

G1 = griddedInterpolant(real(A))

G2 = griddedInterpolant(imag(A))

Hope that is clear to you.

--

Amish

[Ondrej]

Yes, that is clear, thanks. Another workaround I previously used is to save the interpolated arrays and corresponding grid vectors in the file, and create the interpolant only after loading.