Possible memory leak when opening figures that are maximized (2021b)

I'm running 2021b on an Intel i9 Mac (12.1 Monterey) with 16gb of memory.

For me, there seems to be a significant discrepancy between the memory that Matlab uses when I open a figure maximized vs. when not.

The difference is so big that 15ish figures render my machine sluggish and interacting with figures becomes very painful.

Here's some code that illustrates the issue. I "profiled" the code using the Mac Activity Monitor to check the memory that is being used by Matlab. Testcase a) seems to be doing just fine. Case b) uses up to 8 gb of memory and case c) slightly less. Notice, that I am only plotting 3 datapoints per figure.

There also seems to be a disproportionate increase in memory after about the fifth figure. After that, each figure adds more than 1gb of memory, whereas the first five figures behave as expected.

Is this a known issue? Any advice / ideas for how to prevent this from happening?

Thanks in advance!

function test_matlab_memory_issue()
% run one after another to see memory usage
%test_a() % this is okay
%test_b() % this is bad
%test_c() % this is bad, but not as bad as b
end

function test_a()
[x,y,nfigs] = close_clear_clc_get_data();
for i=1:nfigs
    figure()
    plot(x,y);
end
end

function test_b()
[x,y,nfigs] = close_clear_clc_get_data();
for i=1:nfigs
    fig_handle = figure();
    set(fig_handle, 'Units', 'Normalized', 'OuterPosition', [0 0 1 1])
    plot(x,y);
end
end

function test_c()
[x,y,nfigs] = close_clear_clc_get_data();
for i=1:nfigs
    figure('WindowState','maximized')    
    plot(x,y);
end
end

function [x,y,nfigs] = close_clear_clc_get_data()
close all
clear all
clc
x = [1,2,3];
y = [1,2,3];
nfigs = 10;
end

[Kazuhiro Maeda]

I don't know any solutions for it, but I tested your code and found that the same problem occured in my environment (MATLAB R2021a, macOS (11.6.1), Mac Pro).

It is funny that only ten figures with 3 data points each need several GB memory. I think this is a bug. As you pointed out, it might be memory leak.

My test results below:

Memory Usage

Idle: 0.9 GB

Case a): 1.0 GB

Case b): 17.1 GB

Case c:) 13.4 GB

The funny thing is that after I tested Case b) and did "close all” and “clear all”, MATLAB still used "2.7 GB" of memory. Then, I ran Case b) again and it reached 18.6 GB and MATLAB hanged up.

I did the same experiments with Mac safe mode.

Memory Usage

Idle: 1.0 GB

Case a): 2.0 GB

Case b): 3.9 GB

Case c:) 9.3 GB

After Case b) and c), I did “close all” and “clear all”, but MATLAB still used 1.7 GB.

The results for the safe mode are quantitatively very different from those for the normal mode, but qualitatively the same, too much memory used.

Thanks for your post. I knew that MATLAB for Mac often became unstable when I made figures, but I could not reproduce it. Your codes are definitely useful for MathWorks devs.

I have been using MATLAB also on Windows for 15 years, but I haven’t experienced this issue on Windows. I hope we can get more support for Mac.

[Chip Hawkins]

Thanks for the elaborate response. This seems to match my observations quite well. I also had the issue, that doing clear all; close all did not free the memory to the original idle state. Only restarting did.

[Kazuhiro Maeda]

I agree. I did some more experiments.

I ran the code on Windows (MATLAB R2021a, Windows 10 Pro 20H2)

Memory Usage

• Idle: 1.01 GB
• Case a): 1.02 GB
• Case b): 1.44 GB
• Case c): 1.45 GB

After Case b) and c), I did “close all” and “clear all”, but MATLAB still used 1.18 GB and 1.23 GB, respectively.

Also, I did the same test on my MacBook Pro (13 inch, 2020 Intel, Big Sur 11.6.2, MATLAB R2021a):

Memory Usage

• Idle: 0.92 GB
• Case a): 1.56 GB
• Case b): 4.23 GB
• Case c): 3.82 GB

After “close all” and “clear all”, the memory usage decreased to 1.02 GB in Case a), 1.46 GB in Case b), and 1.22 GB in Case c).

Taken together, MATLAB for Windows has the same issue, but not as bad as that for Mac. MATLAB for Windows is probably more memory efficient (for making figures). I’m not sure why the memory usage is so different among Macs. It may be due to the screen size or resolution.

[Keith Myescough]

Is it known whether this is a new issue? I'm concerned we might be seeing the same since switching to Matlab R2022b (from R2020b) last month. We are running an application that generates a lot of figures and we are also using the approach with "set" similar to what is done in case b.

Given the size of the application and the interplay between various parts controling what is plotted, it is very hard (to impossible) for us to switch to a design pattern like case a or c.

[Derek]

I still experience this issue in R2024b.

Answer 1

[VINAYAK LUHA]

Hello Chip,

It appears that you're experiencing high memory usage when generating multiple figures in MATLAB on your MacOS system and you're looking for a way to optimize the memory usage. One effective method could be by changing the renderer for figures from "OpenGL" renderer, which typically consumes more memory to a more efficient "painters" renderer for 2D plots.

The following code sets the default figure renderer to painters.

set(0, 'DefaultFigureRenderer', 'painters');

The higher memory usage you're seeing with MATLAB might be linked to how Java handles memory internally, as MATLAB utilizes Java for some graphic elements. Java creates a pixel buffer for rendering each axes, which is a demanding process and is only executed when the figure is displayed. Java saves memory by avoiding the rendering of images not currently on the screen or by eliminating old, hidden pixel buffers. Docking the figures can noticeably reduce memory usage, which can be done via the 'show plot tools and Dock figure' button or the 'Dock Figures' shortcut. However, undocking the figures into separate windows and accessing each one can cause the memory usage to rise more.

For other optimizations to improve graphics performance, refer to the following documentation -

• https://www.mathworks.com/help/matlab/graphics-performance.html

I hope this information is beneficial to you.

Thanks