MATLAB 2020b slow to return errors

Background

My workplace supports a variety of different Matlab versions with the most current version being 2020b. I've been using 2016a though beacause 2020b is so slow to return errors that makes it unusable.

I put the following code in a test script called speedTest.m that's purposely written to cause an error.

char()+cell(1)

I then ran the script in both versions of Matlab using the profiler to illustrate the problem.

2016a

Running the profiler in 2016a, the script runs quickly and returns the expected error:

2020b

Running the profiler in 2020b, the script is very slow to run and return the expected error:

Things I've Tried

I read this thread that suggests the problem is due to Matlab searching network drive paths for variables and functions which can be slow. My startup script does add a bunch of network drive paths for functions and libraries that our group uses but I run the exact same startup script in any version of Matlab I use. The slow error return has never been a problem in the 4 years that I've been using 2016a. I've been able to get by using 2016a but now I need to work with third party Matlab code that requires a newer version (because the string() function didn't exist in 2016a).

Question

It looks like error checking changed between versions but why is it so much slower in 2020b?

[dpb]

I'd noticed the long time to return after an error, too, but manage to keep going...but I'm not doing extensive production coding that the number of error returns is high enough to be more than an annoyance.

I'll agree it seems the new stuff has real performance issues in comparison....wish they would test stuff more thoroughly and hold off release until such glitches are fixed instead of going ahead with the introduction of the particular feature no matter what...

It would be most interesting if folks with newer releases could run the test case and report what has happened since.

I'm in a state where it's not convenient to upgrade yet, so I'm also still at R2020b; maybe here in a couple months will have the opportunity, but not now.

[Adam Danz]

@Matt McMatlab the second answer in that thread you referenced suggests using RemoveDrivesFromHistory. This is a utility I wrote years ago (well before I was employeed at MathWorks) that, for me, solved the problem you're describing. Matlab stores your current directory history between sessions so it doesn't matter that you're running the same startup across multiple machines. If there's a directory in your cd history that is no long accessible, it could cause this problem in the release you're using.

[dpb]

@Adam Danz: wasn't aware ML was doing such a thing and never cleaning up after itself; discovered stuff in there that hadn't been accessed in a year or more.

Nice tool, thanks for pointing it out and having developed it, but it doesn't seem as though this ought to be something the user should have to do manually. If the problem didn't exist before some prior version, it would appear to the casual user there's something wrong with the implementation if it takes manual intervention to prevent it from wreaking havoc.

$0.02, im(nsh)o, ymmv, etc., etc., etc., ...

[Matt McMatlab]

@Adam Danz I should have mentioned that I had tried your utility a while back but it didn't change things for me and I decided at the time to ignore my problem and keep using 2016a. I just tried it again and there were no network drives listed. There were a few local directories that I had deleted so I removed those but still see the slow error behavior. I tried removing all paths displayed by your tool except for my startup directory but that didn't help either unfortunately. On a windows machine like mine, is your function looking through "C:\Users\%USERNAME%\AppData\Roaming\MathWorks\MATLAB\R2020b\History.xml" for the cd command history? I'm wondering if there's some history file I can try deleting in its entirety. If not, then I may consider a fresh install of Matlab since this wasn't a problem when I first used 2020b.

[Adam Danz]

Thanks for the comments @dpb. Sorry this didn't fix the issue @Matt McMatlab. I found the thread I created years ago that led to my FEX submission.

https://www.mathworks.com/matlabcentral/answers/364153

This thread reminded me that turning off internet prevented the long wait time on errors which led me to learn about the cd history issue.

> is your function looking through ...History.xml" for the cd command history?

No, these data are stored in Settings so file-search isn't needed.

[Matt McMatlab]

@Adam Danz Thanks for the suggestion. Interestingly, I turned airplane mode on and my test case took anywhere from ~0.75 to 3 sec to return the error. So it's much better but still annoying compared to the near instantaneous run time in 2016a. Re-enabling internet caused the issue to come right back with it taking around 30 sec again. I'll give reinstalling 2020b a try next. Maybe that'll clear out something that's causing the lag. I appreciate your help. Given that you went so far as to write a function and release it on the FEX, it sounds like you understand the frustration this issue causes all too well.

[dpb]

@Adam Danz: Has this been fixed/improved in a later release to not be such an issue (albeit it appears that @Matt McMatlab has some other issues going on as well; I've not been a spot that it has showed up as an issue yet since yesterday)?

If it can still be an issue, seems as though there ought to be a note somewhere in the documentation about it...

If it is, seems like a tool similar to yours ought to be packaged with the distribution or referenced there.

BTW, I've not looked at the source code; if it is still a germane tool for current releases; what would it take to introduce a preferences dialog to change the color scheme? I had a real hard time reading some of the text with the contrast on the machine here...

[Adam Danz]

> Has this been fixed/improved in a later release to not be such an issue

Yes but if others experience similar symptoms in recent releases I'd be happy to convey that info.

> seems like a tool similar to yours ought to be packaged with the distribution or referenced there

Thanks for the suggestion!

About my FEX function, when I wrote it I wasn't quite sure how it may impact others' workflows who may use or rely on current directory history so I was cautious and wanted to display the info in an app. The crux of it is working with

S=settings; S.matlab.desktop.currentfolder.History.PersonalValue

But to address your question about color, they are all defined in one variable toward the top. I must admit, awful color choices 😄

gui.colors = [

0.148 0.148 0.148; ... %background, minshaft

0.979 0.500 0.445; ... %Text, salmon

0.660 0.660 0.660]; %bacgkround2, dark gray

[Chris]

I have some network locations behind a VPN.

Windows Explorer has a really hard time dealing with this if I'm not connected through the VPN (around a 20-second delay, which seems right for this thread). If the drive is mapped, the delay affects pretty much every operation I attempt in Explorer (I quickly learned to stop mapping network drives).

If I try to add one of these network paths to Matlab in a startup script in R2022b, Matlab will experience the delay.

There's an old thread attempting to address the Windows problem here, but I'm not sure if it solves the problem anymore.

If this is the same problem as @Matt McMatlab is experiencing, I wonder what's different about R2016a.

[Adam Danz]

I've experienced this as well, @Chris. The comparison between 2016a and 2020b made by the OP focuses on how long it takes to throw an error related to an unknown function or variable whereas your remarks seem broader.

Related threads to slow network performance:

• https://www.mathworks.com/support/search.html/answers/218760
• https://www.mathworks.com/support/search.html/answers/606506

[dpb]

>> errorSpeedTest
Elapsed time is 0.000603 seconds.
>>

where

>> type errorSpeedTest
tic
try
  char()+cell(1)
catch
  toc
end
>> 

On reflection, I realized the time I see delays is not on an error, but when I mistype a variable name and it's doing the search for the non-extant function. That seems quite a lot longer than earlier releases, but I don't have any older presently installed to test and I suspect it's heavily correlated with so much new stuff been added to the dictionary to search. And, that also seems to be dependent upon just the exact syntax used; I've yet to be able to identify a pattern in when do/don't experience the delay. I'll try to remember to be more attentive...

I also have mapped network drives behind the VPN; I can't do a lot of the work I've been doing without access to the shared drive as it's just become too cumbersome to try to keep local copies in synch.

The connection may temporarily go down and have to reconnect, if I've got the needed data already in memory or the temporary local copy of a spreadsheet already open, then it doesn't really matter unless I do need immediate access to the drive again, but I don't seem to see any real difference between whether the drive is/is not connected otherwise.

I can run my batch file to reconnect them manually after a loss of connection if need immediately after the connection is restored rather than waiting on the OS to automagically reconnect that can take a while.

[Paul]

Adding my $0.02 anecdotally .... I recall having the same problem as @dpb where if I fat-fingered a variable name at the command line it would take interminably long, i.e., not instantaneously, to return the "Unrecognized function or variable ... " message. I never did track down when it occured as I sometimes work in airplane mode, on the internet w/o VPN, and on the internet w/VPN, with the latter using a different licensing scheme. Now that I think about it, I don't recall having that issue in a while, but I'm up to 2022a now. If interested, I might be able to track down the release in which I was having that problem.

[Chris]

My thought process was, the network drive is at the top of the search path. If the connection is dropped (or refused?), the delay will occur when Matlab looks there first. Indeed, the first time I try anything in Matlab (any function, doesn't have to cause an error. "1+1" does it) after disconnecting from the VPN, the delay occurs. Something happens after that first attempt that prevents the delay for that function, but now try "1-1" and there's the delay again.

On the other hand, if Matt's problem is really only triggered by calls to error(), then perhaps it's unrelated.

For the record, I think these servers use smb (though I'm not sure how Windows would know that before connecting)

@dpb interestingly, your speed test doesn't catch the 20s delay.

[Matt McMatlab]

@dpb I ran the same test as you with the faulty char()+cell(1) command within a try-catch statement and it ran in 0.002916 sec for me. So it seems like the issue only happens when Matlab is actively returning the error which I think is why we've all seen it at some point when doing something as simple as mistyping a variable in the command window.

@Chris I have mapped network drives that I can only access through our VPN. Older projects in our group are stored on the network drives so there's no way around needing to work off of them but I don't have issues accessing them in Matlab. It's definitely slower than working off a local drive but I think that's just my VPN throttling me and not the fault of Matlab. I have experienced the delay you described when the VPN connection drops though. I've always assumed it was because Matlab was trying to reconnect to the license server since it happens to me in both 2016a and 2020b. I usually type in something like "1+1" and once it finally runs, then I'm good to go until the next time the VPN drops out.