Matlab calculations randomly take forever to run, not represented in tic toc

Hello all, I have a weird issue I was wondering if someone might have some idea on how to fix. I'm running Matlab 2024b on a Dell XPS 14 laptop. My issue is that seemingly randomly (perhaps 1 out every 6-10 operations) Matlab takes forever to run selected lines of code (or anything at all). For instance, I just ran this line of code:

  tic
    ECR_PBO_Support_1 = [];
    ECR_PBO_Support_2 = [norm_2_32_PBO_Support01.ECR, norm_2_32_PBO_Support02.ECR, norm_2_32_PBO_Support03.ECR, norm_2_32_PBO_Support04.ECR, norm_2_32_PBO_Support05.ECR,...
                           norm_2_32_PBO_Support06.ECR, norm_2_32_PBO_Support07.ECR, norm_2_32_PBO_Support08.ECR];
    ECR_PBO_Support_Total = [ECR_PBO_Support_1,ECR_PBO_Support_2];
  toc

What the data is is irrelevant (its ultimately 8 vectors of 100 numbers long). But when I ran these lines, Matlab took about 5-8 seconds to run (i.e. it displays 'Busy". Even though the output of tic toc was:

Elapsed time is 0.015314 seconds.

For the life of me, I cannot figure out why Matlab is doing this, but its causing me to really slow down since even the most basic operations will randomly take 5-8 seconds to run. When it happens, the delay affects everything, calculations, plots etc.

Has anyone experienced this before or have any suggestions for settings to check?

[Matt J]

What kind of license do you have?

[Nathan Thompson]

Its through my institution, but I'm not clear if its 'designated computer' or 'individual'. Both show up when I look up my account information.

[dpb]

ECR_PBO_Support_1 = [];
ECR_PBO_Support_2 = [norm_2_32_PBO_Support01.ECR, norm_2_32_PBO_Support02.ECR, ...
                     norm_2_32_PBO_Support03.ECR, norm_2_32_PBO_Support04.ECR, ...
                     norm_2_32_PBO_Support05.ECR, norm_2_32_PBO_Support06.ECR, ...
                     norm_2_32_PBO_Support07.ECR, norm_2_32_PBO_Support08.ECR];
ECR_PBO_Support_Total = [ECR_PBO_Support_1,ECR_PBO_Support_2];

What's the point of ECR_PRO_Support_1 in the above code snippet? It has no impact other than additional do-nothing instructions to be executed.

More to the point, how large are the elements being catenated? The use of the [] may be causing memory reallocation and the effects you're seeing may be owing to memory paging and reallocation if either these are large or there are other large arrays in memory (or there are other memory-intensive processes also running that are being swapped).

The use of a large number of sequentially-numbered variables is also an indication of a less-than-optimal memory allocation and use of MATLAB; creating an array instead would make coding and processing a lot simpler and possibly quite a lot faster as well.

[Catalytic]

Try switching to software opengl and see if that changes the frequency of the slowdowns -

opengl software

[Nathan Thompson]

So set aside the specifics of whats contained in the copy and pasted code (yes I'm aware its less than optimal, and the empty matrix is simply because its part of a large structure which is how I like to read it).

For instance, even if I run:

A = 2; B = 1; C = 15; D= [A,B,C,D];

The same behavior would result in some cases. I also know its not a specific optimality issue, because if I run the same block of code over and over, yes most of the time it runs and prints as fast as tic/toc would indicate, but sometimes it takes 6-10 seconds. Again its only maybe one out of every 5-10 commands this happens. It seems to happen more often with plots, and more often when doing something that needs to print the result.

But it so far it has nothing to do with the perceived memory usage of the command itself.

[dpb]

Is the machine on a network; is everything a local copy if so?

You have a mapped network drive, by any chance? That's about how long it takes here for a net use command to time out if the VPN goes down before it's restarted and the network connection is restored.

It's got to be something like memory disc paging or waiting for network access or the like...what about the license server access, maybe?

I doubt anybody on Answers forum is going to be able to do more than conjecture such as I have; submit this to Mathworks as an official support request at <Product Support Page>, they can help diagnose what is going on.

[Walter Roberson]

Note by the way that opengl software is relevant for R2024b (release being used by user) and before; as of R2025a it is ignored.

[Nathan Thompson]

Ok, a couple updates. I still dont know the cause. I tried switching to opengl, but then Matlab promptly froze. I am working off a laptop, that is (currently) not connected to a network, and all files are stored locally on the hard drive. I also use this computer on a network, though in that case I still get the same issues. On this laptop the user profile I am using is not an admin, though I have access to the admin profile. Perhaps there are processes that ping the admin profile from time to time?

Either way, I did install Matlab 2025b, and Ill report back and see if it continues there.

[Matt J]

Is it a new laptop? Make sure your graphics card driver is up to date.

[dpb]

Could you install R2022b, say, just to see if there's something version-specific happening? Multiple MATLAB versions will coexist happily with each other so don't have to uninstall current.

Also, I presume you have checked and that do have latest MATLAB updates on preesent version?

[Steven Lord]

If this is on Windows, can you bring up Task Manager and run the lines of code that "take forever to run" while watching what Task Manager says is consuming the most CPU, memory, disk, and network resources? I'm wondering if something is triggering an anti-virus or anti-malware routine to do additional scanning and that Windows isn't "paying attention" to MATLAB during that time.

[Nathan Thompson]

A couple of follow ups. So it was never any specific lines of code that would cause the slowdown, it almost seemed like a time factor. Like if I hadnt run any code in the last few minutes, it was destined to happen with the next line I ran. Once it happened I was clear for another few minutes. But yes I suspect some process that windows didn't like was triggered, Matlab believed it was done running, but Windows didnt let matlab update or something.

I will say I finally updated to 2025b, and I'm no longer experiencing it. So I suppose that counts as a fix!

[dpb]

If you didn't uninstall R2024a, did you try running after disabling any anivirus or other watchdog apps (temporarily)?

[Walter Roberson]

It almost sounds as if it is doing license checking against a remote system and waiting for the (unconnected) internet to time out. Is it possible that you have configured a remote license server as a secondary license server?

[Nathan Thompson]

I have not tried disabling antivirus. @Walter Roberson that thought crossed my mind that it was trying to connect to something and then timed out. How would I check this?

[dpb]

The license server timing out was one of my first conjectures, too. But, I'm not positive about how to tell, sorry, since don't have network license.

ADDENDUM

It appears that for a network installation, there is a network.lic file at %matlabroot%\licenses that contains the information.

A <prior question answer> says you can query the status with the lmutil app; that doesn't exist locally since have standalone single-user license, but should show up on your laptop...

Answer 1

[Benjamin Kraus]

@Nathan Thompson two questions:

1. Do you have a figure open that contains a lot of data?
2. Are you using linkdata?

I've seen an issue like this in the past where linkdata is enabled, and whenever the MATLAB workspace changes, linkdata is attempting to update any open figures based on the change in the workspace. This can cause symptoms that look like this, if the figure itself contains a lot of data (and is slow to update).

Either way, if you want to identify what is taking so long, do this experiment:

1. Enable the profiler by running profile on
2. Run whatever code is causing MATLAB to sit busy for a few seconds.
3. While MATLAB is sitting busy, type profile off at the command line and press enter. You can do this even though MATLAB is busy. The actual command will be queued and will run as soon as MATLAB goes idle again.
4. Once MATLAB is idle, run profile viewer to see what was occupying so much time.

Note: You cannot do this using a script or the experiment won't work. Step 1 and 2 can be run together at the same time, but you must run steps 2 and 3 separately (one at a time) in the command window. Step 3 can be run once MATLAB is idle, and it shouldn't impact much other than the overall time, so don't stress too much about running step 3 quickly.

Once you've looked at the results, if you are comfortable sharing the results, run this command:

p = profile('info')
save profile_results p
version

Then reply to this post with the output from version and attach profile_results.mat to the reply.