MATLAB Answers

Klaus G
2

Slow plotting performance starting from Matlab R2014b

Asked by Klaus G
on 16 Apr 2015
Latest activity Commented on by Steven Lord
on 24 Mar 2017
I observed considerably worse performance of Matlab plot functions with versions R2014b and R2015a compared to earlier versions. Some of my interactive plots became almost unusable. For example, for one of my plots with 6 subplots and about 1000 data points each, the update of the plot is rather fast (<100ms) but then it takes about 30s until the plot is responsive and the command line is free. Using tic/toc and profiler I was not able to figure out where Matlab spends the time. It seems to be a problem related to the new graphics engine introduced in R2014b.
A small example (extreme case with many data points) shows how much slower plotting performs with R2014b/R2015a compared to R2013b in the case of many data points:
xx=randn( 1e7,1);
figure(1)
tic;
plot( xx, 'x');
drawnow;
toc
System 1:
  • CPU: Intel Core i7-3930K
  • GPU: Nvidia GeForce GTX580
  • RAM: 64GB
  • OS: Windows 7 Enterprise 64bit
  • Matlab 64bit
  • All drivers are up to date.
R2013b: Elapsed time is 2.207543 seconds.
R2014b: Elapsed time is 37.758890 seconds.
R2015a: Elapsed time is 35.490439 seconds.
System 2:
  • CPU: Intel Core i5-2500K
  • GPU: Intel HD Graphics 3000
  • RAM: 32GB
  • OS: Windows 7 Enterprise 64bit
  • Matlab 64bit
  • All drivers are up to date.
R2013b: Elapsed time is 2.402014 seconds.
R2014b: Elapsed time is 62.260723 seconds.
For the R2014b/R2015a version there is in addition this function execution time a time interval of several tens of seconds after plotting until Matlab is responsive. This time interval is negligible for the R2013b version.
Furthermore, I observed huge differences in memory consumption of Matlab. After executing the commands above, the Windows task manger shows following memory consumption values. Maybe this is related to the slow plotting performance.
R2013b: ~600 MB
R2014b: ~12 GB
R2015a: ~11 GB
Does anyone observe a similar behavior and know how to solve this problem?

  4 Comments

Show 1 older comment
I just recently "upgraded" from R2013a to R2015a and am painfully experiencing this in my existing tools (which plot large amounts of data). Has it been addressed or have work-arounds been found? I'm trying to determine if I need to go back to a pre-R2014b version in order to be able to function.
Same here. Basically 2015a unusable for many of my scripts that generate figures. ...particularly maps. Going back to 2011a it works as it should. This is exactly why I keep an older version on my computer.
If possible, try obtaining a trial of release R2016b or later and evaluating the performance using that release. The Release Notes indicate "Graphics that contain large numbers of markers have improved performance and use less memory."
If you do obtain a trial and still see performance that's slower than you expect, need, and/or want please send an example of your code that's slower to Technical Support so they and the development staff can identify why it's slow and work to improve the performance of the performance bottleneck(s) for that case.

Sign in to comment.

1 Answer

Answer by Mike Garrity
on 28 Mar 2016
 Accepted Answer

The difference between the two versions is really a bit too complex to capture in a single number. I've been going into some of the details on the MATLAB Graphics blog.
My guess from your example is that what you're seeing is marker drawing performance. I don't think that I've covered that one well in the blog. The short version is that all of the graphics functions now share a single marker drawing implementation. This new version is faster than some of the old ones (e.g. the scatter example in this post ), but slower than the fastest of the old ones (which is the one you'd be getting here with plot). We're still working on tuning this up, and you should see some improvements as each new release comes out.
The one special case in marker drawing which is important to know about is that the '.' marker translates directly to an OpenGL primitive, and is much faster (and uses less memory) than all of the others which require a lot of shimming.

  1 Comment

Mike - That fits with what I am experiencing. The marker drawing now seems to be my bottleneck. I was able to improve much of the rest of the slow down by using reduce_plot from the File Exchange (with modifications - adding a method so I can interactively change my x-variable being displayed). So now I just have to sit and wait for a minute or two (sometimes 5) while the markers first display before I can interact with the plots. The markers plotting for the same data set rendered in about a second in R2013a. Once the markers do finish rendering in my R2015a implementation, the subsequent interaction is now acceptably fast (using the modified reduce_plot).

Sign in to comment.