I have been a Matlab loyalist for 25 years
I have been a loyal MATLAB user for 25 years, starting from my university days. While many of my peers migrated to Python, I stayed for the stability, compatibility, and clean environment. However, I am finding the 2025 version exceptionally laggy. Despite running it on an $10k high-end machine, simple tasks like viewing variables and plotting take up to 60 seconds - actions that were near instantaneous in the 2020 version. I want to stay continue with MATLAB, but this performance gap is a major hurdle and irritation. I hope these optimization issues can be addressed quickly.
13 commentaires
Date décroissante
@Jan Christian Could I contact you please to arrage a video call? I've reported your case to development and they need a little more information.
I understand you @Jan Christian. I've also been a MATLAB user for many years and have always been obssessed with MATLAB performance. Making MATLAB code faster was the backbone of how I started my career as a Research Software Engineer.
Since I've joined MathWorks, performance is still once of the top things I concern myself with and MathWorks internal enhancement tracking database is full of issues from me saying things like 'I've noticed this could be faster' or 'I saw this user complaint on MATLAB answers and reproduced it'. Even though I am not in development, one of the things I'm proud of is that there are always several things in every MATLAB release that I can point to and say 'The internal thread that led to that enhancement came from me' and many of them are performance related. There are many at MathWorks who do similar.
I'm telling you this to assure you that comments like yours are noticed, read and acted on. Thank you for sharing and please keep the feedback coming.
This thread led me to including a performance section in my blog post about R2026a MATLAB R2026a has been released – What’s new? » The MATLAB Blog - MATLAB & Simulink. In the blog I only cover a fraction of what's been made faster -- the full list is in the release notes.
The performance that I was talking about in another comment of this thread, and what I believe the original poster intended, is macroscopic. Specific functions are very easy to clearly define and measure. However, overall use of the app is often harder to diagnose.
Unfortunately, I am in the same camp as @Jan Christian in that I have a very expensive computer (Intel Mac) on which R2025a and R2025b are very laggy compared to R2024b. Specific slow-down scenarios include stepping into and out of the debugger and opening the variable editor. While I have no doubt that much of the built-in functionality of R2025b is faster than that in R2024b, on some hardware other aspects of the app have become so much slower as to make all such performance improvements unnoticeable.
The debugger has definately slower post-Java. One of my new pet peeves is how a debugger tab gets added to my minimal "command window only" interface. This happens whenever time debugger starts, i.e. I have to close that tab every time. Maybe I'm a purist, but screen space is still precious to me...
I can confirm slowdowns on the Mac side, where I use MATLAB most often. I had to abandon earlier releases becuase they repeatedly crashed not matter what Java library I tried.
What hardware are you running? I have similar problems of lagginess, especially for stepping into and out of the debugger, as well as with the variable viewer. I am using R2025a and R2025b on an Intel Mac Pro. At times, I also use R2024b (before the new desktop), as it does not experience these specific slowdowns.
There definately are a lot of rough edges in the Java to Javascript transition of 2025a. The standard answer, as you surely know, is that the released release 2026a is much better. There are definately improvements, but I also cannot shake the feeling that a lot of the plots are slower than they were ten years ago. Heck, they still have not addressed a physical sizing problem created over ten years ago in the HG2 transition.
I'm using Matlab since 1996. The graphic perfomrance degraded contantly. I had to create some 10'000 pages of PDF with 15 diagrams per page for a medical long term study. The performance of modern Matlab versions was too slow, so I was faster running Matlab 6.5 in a virtual Win7 machine. Of course, I had to create some workarounds for the backward compatibility: endsWith, startsWidth, extractBetween, contains, openedFiles, catch with MException, groot, block comments, ... But even considering this effort reduced the time for solving the problem.
It is a smart idea to reduce the dependencies of the graphic engine to the operating system. So introducing HG2 and the AppDesigner as well as uifigures had several advantages, but the performance and clarity got lost. Standard interactions with the GUI suffer from an exploding complexity, e.g. the determination, if a HG-handle belongs to a figure or uifigure. See e.g. https://www.mathworks.com/matlabcentral/answers/348387-distinguish-uifigure-from-figure-programmatically
I have the impression, that the problem of the exploding complexity occur in the toolboxes also. The command "depfun" was replaced by "matlab.codetools.requiredFilesAndProducts".
The modern datetime objects are very tough and powerful. If you have to convert a million of "08-Jun-2004 00:31:37" strings or CHAR to date vectors like [2004 6 8 0 31 37], datetime is even slower than datestr and a hardcoded tool can be 100 times faster.
The flood of new options allows to use MATLAB for more and more purposes. Although the power of MATLAB grows, it becomes more and more a bloatware.
I see several scientific labs, which stick at a specific MATLAB version to avoid the incompatibilities. The pile of new features are the cause to avoid an upgrade. I'm developping tools for medical research and distributed to several labs. This is very difficult today due to the incompatibilities between the MATLAB versions. See e.g. the problems to hide or show figure toolbar instroduced in R2018b. Even the workarounds are working in some versions only:
The increased prices for student and home licenses are a decision also, which reduces the interest in this programming language. The traffic in the community is much less than 3 years ago. The charm has gone.
MATLAB was a part of my "hometown". I don't feel trusted anymore.
The graphics haven't been constantly degrading - there was a significant improvement in pcolor some time around 4.1 - 5.2...
It does seem like MathWorks has focused so heavily on expanding functionality that they have lost sight of performance.
I would rather have 10 tools that work extremely well than 100 tools that work fairly well.
Thanks, goc3. The support of different Matlab versions gets harder and harder, while upgrading is not an option for some users due to the reduced performance.
I'm struggling with another problem, which seems to be caused by the exploding complexity: https://www.mathworks.com/matlabcentral/answers/2183503-how-to-find-a-function-in-the-path-securely
The function which() cannot find a function in Matlab's path reliably. Matlab's internal method to identify dependent functions matlab.codetools.requiredFilesAndProducts() use a set of over 200 subfunctions with a high complexity and > 521 kB of code (R2018b).
The effect of an exploding complexity is known in large software projects. Different groups in the development team try to build their new additions on top of a working system, such that more and more layers grow like an onion. The solution is easy: Refacturing - rebuild the complete code from scratch considering the wanted behavior from the beginning.
Connectez-vous pour participer
Tags
