MATLAB Answers

Code in live script run much slow

193 views (last 30 days)
Xinyu Zhang
Xinyu Zhang on 13 Nov 2016
Commented: jdg on 10 Jul 2020 at 10:37
The new matlab live script functionality is really awesome, thanks matlab team.
But I observe that my code run considerably slower in live script than in the command line. Just out of curiousity, is this an expected result for a newly created function or there is some way to configure the amount of resource allocation for live script? Thanks.

  3 Comments

Lukas Müller
Lukas Müller on 25 Nov 2017
just want to add my case to the needed update in performance in matlab livescript. The following code
x1_ini = -147143866;
x2_ini = 3391949;
v1_ini = -0.68641;
v2_ini = -30.2659;
max_dev = 0.1*6371;
earth_sun = 149600000;
orbit = 2*pi*earth_sun;
v = norm(v1_ini+v2_ini);
dt = 1;
while true
n = 1;
while v*dt*n < (orbit-max_dev)
n = n+1;
end
if v*dt*n + v*dt > (orbit+max_dev)
break
end
dt = dt+1;
end
dt_max = dt-1; %= 24
takes a couple of seconds as .m file and isn't yet finished computing after 3 hours as livescript ...
Noam Segev
Noam Segev on 24 Feb 2019
It is a bit ungainly, but you can save the file as .m file and run the heavy sections from this file, and then continue with livescript for sections that needs the represenations.
Matt J
Matt J on 28 Feb 2020
Does anyone know if the speed issue extends to Live Functions?

Sign in to comment.

Accepted Answer

Philip
Philip on 5 Mar 2020
Edited: Philip on 3 Apr 2020
This issue has been resolved in R2020a, R2019b Update 5, and R2019a Update 8. Live scripts with loops now run as fast in the Live Editor as in the Editor or at the command line.
With the change, the approximate execution times of the example above are:
R2018b: 200.2 s
R2020a: 0.160 s
The code was timed on a Windows 10 system with a 3.6 GHz Intel Xeon W-2133 CPU.

  6 Comments

Show 3 older comments
madhan ravi
madhan ravi on 26 Apr 2020
Do you also face the same in MATLAB online @Gerhard?
Philip
Philip on 27 Apr 2020
Hello,
I am sorry to hear that you are still having an issue with the performance of running in the Live Editor. That is definitely unexpected behavior. Please feel free to reach out to technical support or contact me directly to investigate the slowdown.
Thank you,
Philip
jdg
jdg on 10 Jul 2020 at 10:37
Agree with Mike that things are not better. I am trying out Live Editor in R2020a on a MacBook Pro running macOS Catalina (v10.15.5). After experiencing very sluggish performance I came across this page.
One thing I noticed is that evaluating runtime in the .mlx file with tic/toc is misleading. The blue circle and pause button (both indicating the script is running) are present for much longer than the script is actually running. I had to time it manually to get an accurate estimate.
For example, the code below takes ~2 seconds in an m-file on my machine.
Running it in a .mlx file, I get tic/toc results of ~2.5 seconds. However the script is in executing mode (blue dot) for anywhere from 9 - 30 seconds.
Not looking for suggestions on how to improve the code itself. It's obviously very poorly structured.
@Philip Can you try this code on your machine? I am wondering if it's a Mac issue.
clc
tic
for A_gain = [0.5:0.1:1]
for A_phase = linspace(30,60,5)*pi/180
for B_gain = [0.5:0.1:1]
for B_phase = linspace(80,120,5)*pi/180
A = A_gain*(cos(A_gain) + j*sin(A_gain));
plot(real(A),imag(A),'b.');
B = B_gain*(cos(B_gain) + j*sin(B_gain));
plot(real(B),imag(B),'r.');
c = A+B;
plot(real(c), imag(c),'o');
hold on;
end
end
end
end
toc

Sign in to comment.

More Answers (7)

Gijs van Oort
Gijs van Oort on 31 May 2017
The most annoying I think, is that editing is much slower too. After pressing a key, it takes noticeable time for the character to be shown on the screen. Also walking through the code with the arrow keys and scrolling are really slow. Due to this, I'm now ending up writing my code in a normal .m script and copying it to the .mlx when I'm happy with the results.

  1 Comment

Gijs van Oort
Gijs van Oort on 28 Jun 2017
In the LiveScript, I was displaying some very long symbolic equations. I found out that this greatly reduced speed and responsiveness. It was useless anyway; 90% of the displayed equation would be typeset off the screen. After I disabled the displaying of the equations (adding a ; after the assignment), the thing became much faster (but still slower than I would wanted it to be)

Sign in to comment.


Prannay Jain
Prannay Jain on 15 Nov 2016
Yes, the code runs slower in the live script than in the command line. Currently, there is no way to configure the amount of resource allocation for the live script.
I work for MathWorks and I have forwarded this feedback to the appropriate product team.

  7 Comments

Show 4 older comments
Pierre-Francois
Pierre-Francois on 15 Mar 2018
Any news on this topic? The awful sluggishness of the live script makes this otherwise very promising and appealing tool completely useless. Really too bad !
Jan Kappen
Jan Kappen on 13 May 2018
I have the feeling, being behind a corporate proxy makes things much worse. When I'm at home office without proxy the editor is much quicker. Do you experience the same?
Dom Dwyer
Dom Dwyer on 14 Jan 2019
has this been fixed yet? we can't work with this product currently as it is too slow even on new computers

Sign in to comment.


Tom Anderson
Tom Anderson on 9 Jan 2017
Edited: Tom Anderson on 16 Jan 2017
Please improve this! It's almost 50% slower to run .mlx versus .m...
I ran a code section for a live file using "Run Section" that took 72.971023 seconds. The same code .m file using "Run Section" took 52.701320 seconds. Repeated this test multiple times and .mlx is always a loser.
That's not very good. It's almost a 50% slowdown. It's not as though there's any extra interactivity between the code, either. Just waiting for the results both times, with the GUI locked up.

  1 Comment

Tom Anderson
Tom Anderson on 16 Jan 2017
Here's a great example I found to run much slower:
tic
for t = 1:1000000
if ~mod(t, 10000), disp(t), end
end
toc
The live code (.mlx): Elapsed time is 487.6064 seconds.
Hit F9 to run (or run as script): Elapsed time is 0.010989 seconds.
50,000 times slower? What gives?

Sign in to comment.


Ryan
Ryan on 25 Mar 2017
I will definitely use this feature more when resource allocation improves.

  0 Comments

Sign in to comment.


Florian Blanchet
Florian Blanchet on 11 Dec 2019
Hi,
Can you remove that feature or at least make it clear that is significantly slower and will reduce editor experience ?
How can you provide a feature that is so unusable without make it explicit it is still experimental ?

  0 Comments

Sign in to comment.


Frieder Wittmann
Frieder Wittmann on 28 May 2018
Has this been addressed in R2018a? Didn't see anything in the release notes.

  2 Comments

Will Perdikakis
Will Perdikakis on 28 Aug 2018
Nope. Still brutally slow edits and execution.
Frieder Wittmann
Frieder Wittmann on 3 May 2019
We're at 2019b now and despite all the advertisement for the future it is still unusable slow :-(

Sign in to comment.


Juan José Trujillo
Juan José Trujillo on 17 Sep 2018
Hi,
I do not know what is the motivation for you to use the live scripts. I really find this a cool way of documenting and something which approaches a bit what you can do in Jupyter Notebooks.
In fact, I have been using successfully Jupyter Notebooks with the matlab engine in the last two years to run matlab code. I have worked that way since I have some python background and did not know live scripts until recently. Just lately I have got in touch with matlabs live scripts through a colleague and we have noticed latency which I do not experience through Jupyter Notebooks. I guess the mechanics here are really different and the Notebook approach almost resembles running bare scripts with a bit of overhead on the matlab engine.
Maybe you can give Jupyter Notebook a try and get better performance and with slightly better documentation capabilities with markdown.

  4 Comments

Show 1 older comment
Frieder Wittmann
Frieder Wittmann on 26 Sep 2018
I use Jupyter and like it but still prefer MATLAB due to its build in debugger, profiler and access to the workspace. Also, I like that I can run commands in the command window and combine this with results from scripts.
Juan José Trujillo
Juan José Trujillo on 7 Nov 2018
Hi Kouichi, sorry for answering that late. I am not really into it. But, As I understand the Matlab engine in Jupyter is just a thin wrapper which passess commands straight to a headless matlab instance. In fact any time a launch a matlab notebook I get fully new instance of Matlab working in the background. So I think you get the best of both worlds, or almost depending on the application. As Frieder says, still there are several applications that you do not have access to from the Jupyter Notebook.
A really cool application of this is for instance if you work on a remote headless system with long lived sessions. You just turn on and off your graphical interface (web browser) locally and connect to the server when you need it, but the Jupyter server and matlab instance stay alive on the remote side. I think you cannot do this kind of things with the matlab IDE, or correct me if I am wrong.
Kouichi C. Nakamura
Kouichi C. Nakamura on 18 Dec 2018
Thank for the information about the backstage of Jupyter. Yeah, that makes sense!

Sign in to comment.


Translated by