- Undocumented Matlab - https://undocumentedmatlab.com -

Pause for the better

Posted By Yair Altman On August 29, 2012 | 16 Comments

A few days ago, blog reader Tomás Peyré commented [3] on the fact that the pause function has a memory leak on R2011b and R2012a, and advised using the Java Thread.sleep() [4] function instead. This got me started on a comparison between these seemingly-equivalent functions. It turns out that the Java variant not only does not leak memory like its Matlab counterpart pause – the Java function is also much more accurate in its pause duration.

Testing the pause accuracy is quite simple: Simply pause a pre-defined duration and measure the actual time span. I run this 100 times to get some meaningful statistics. Note that the only difference between the loops below is the pause function that is being used (see highlighted rows):

% Some initializations
timesToRun = 100;
duration = 0.25;  % [secs]
% Measure Matlab's pause() accuracy
tPause(timesToRun) = 0;  % pre-allocate
for idx = 1 : timesToRun
   pause(duration);                        % Note: pause() accepts [Secs] duration   tPause(idx) = abs(toc-duration);
% Measure Java's sleep() accuracy
tSleep(timesToRun) = 0;  % pre-allocate
for idx=1 : timesToRun
   java.lang.Thread.sleep(duration*1000);  % Note: sleep() accepts [mSecs] duration   tSleep(idx) = abs(toc-duration);

The results are consistent and conclusive:

Functionmedian inaccuracymean inaccuracymax inaccuracymax inaccuracy as % of total (250 mSec)
Matlab’s pause()2.0 mSec3.6 mSec12.8 mSec5.1%
Java’s Thread.sleep()0.01 mSec0.02 mSec0.53 mSec0.2%

When the pause duration is reduced to 50 mSecs (0.05 secs), the results are even more striking:

Functionmedian inaccuracymean inaccuracymax inaccuracymax inaccuracy as % of total (50 mSec)
Matlab’s pause()11.6 mSec12.5 mSec15.5 mSec31%
Java’s Thread.sleep()0.78 mSec0.77 mSec0.84 mSec1.7%

When the pause duration is further reduced, Matlab’s inaccuracies increase (120% at 0.01, 370% at 0.005) to a point where we cannot in practice rely on them. Apparently, Matlab’s pause function has an inherent inaccuracy of several mSecs that increases as the pause duration decreases. The effect of increasing absolute inaccuracy with decreasing total pause duration is catastrophic. On the other hand, Java’s inaccuracy remains stable at <1 mSec, making its relative inaccuracy degradation much more gradual and acceptable (8% at 0.01, 20% at 0.005).

Matlab’s pause function has an important side-effect, that may partly explain the discrepancy: Whenever pause is called, the graphics event queue (EDT [5]) is flushed, thereby updating all Matlab figure windows. In my tests above I did not have any open figures, otherwise I suspect the discrepancy would only have been larger. This side effect is actually quite important [6] when integrating Java GUI components in Matlab figures.

Java’s Thread.sleep function, like Matlab’s pause(), is not guaranteed to pause for the exact duration specified. However, as the above results clearly show, in practice the Java variant is much more accurate than Matlab’s. So if you want accurate and leak-free pauses, and do not need the EDT side-effect, I really see no reason to use Matlab’s pause. Sleep() over it…

Categories: Java, Low risk of breaking in future versions, Stock Matlab function

16 Comments (Open | Close)

16 Comments To "Pause for the better"

#1 Comment By the cyclist On September 4, 2012 @ 7:58 am

A couple comments:

First, the results may be platform-dependent. Running R2012a on a Mac (OS X 10.6.8), I get more comparable inaccuracies for MATLAB and Java. Mean inaccuracy for MATLAB is about 0.38 msec, and Java is about 0.26 msec. Also, unlike your results, those inaccuracies are roughly constant when I reduce the input duration.

Second, I notice that one does not need to take the absolute value as you did. The error is systematically positive. This is presumably because both MATLAB and Java choose to pause for at least the prescribed duration.

#2 Comment By Yair Altman On September 4, 2012 @ 8:04 am

@Tim – Thanks for your comments. Unfortunately, at least on Windows the error is sometimes negative, hence my use of abs().

#3 Comment By Andrew On September 6, 2012 @ 7:56 am

Hi Yair,
I have noticed that there are issues with MATLAB hanging up when using inputdlg and other modal dialog boxes. These issues are solved by putting a pause after the dialog box is closed. I’m assuming this has to do with the queue being flushed, as you mentioned. Is there a different way to deal with these issues other than using pause?

#4 Comment By Andrew On September 6, 2012 @ 7:59 am

It looks like using drawnow has the same effect.

#5 Comment By Yair Altman On September 6, 2012 @ 8:07 am

@Andrew – thanks for mentioning this. This is indeed the case, and quite possibly deserves a dedicated article because it is such a frustrating and common issue, that exists in many Matlab releases, and because the solution (adding a pause or drawnow) is so frustratingly simple and yet undocumented. As noted [6], drawnow is similar but not exactly the same as pause. I often use both of them, since I found out by trial-and-error that different situations respond better to either of them, and I never remember which one to use… So I often have lines such as the following scattered around my code (I know it’s ugly, but it works and that’s what matters in the end):

drawnow; pause(0.05);  % or reverse this order

To your question, I do not know of any simpler or better way to solve these hangups.

#6 Comment By Ang On October 17, 2012 @ 1:23 am


Nice article!

It turns out that I could handle an event during pause, but not when I use Thread.sleep.

For example, it’s possible for an event handler to do something to interrupt the while loop here:

global KeepRunning
KeepRunning = true;
while (KeepRunning)
  % It's possible for the event handler to change KeepRunning to false when an event is fired.

Yet, this is not possible when Thread.Sleep is used.

global KeepRunning
KeepRunning = true;
while (KeepRunning)
  % This loop will continue running, no chance is given to the event handler to do anything.

Do you experience the same thing? I’m using Windows 32-bit MATLAB. In any case, I’d like to try and see where I can put Thread.sleep for my future MATLAB programs.


#7 Comment By Yair Altman On October 17, 2012 @ 11:47 am

@Ang – yes, I have also seen this. I am not exactly sure why this happens. It is probably [13]-related, but I am not sure exactly how or why.

#8 Comment By kits On November 2, 2012 @ 11:55 am

Try adding a “drawnow;” in that loop?

#9 Comment By Doug On January 30, 2013 @ 1:18 pm

Thanks for the `drawnow;` recommendation! It made this all work perfectly for me.

#10 Comment By Marc On February 5, 2013 @ 3:48 am

The following patch worked for me to correct this memory (and windows handle!) leak on 2012b:

Since the problem seems to be inside drawnow, using sleep+drawnow probably doesn’t help.

#11 Comment By Yair Altman On February 5, 2013 @ 4:09 am

@Marc – thanks for sharing. According to the patch description, it is not directly related to pause, but perhaps the issues are somehow related.

#12 Comment By Marc On February 5, 2013 @ 4:38 am

As far as I can see, pause() calls (a part of) drawnow to flush the queue. Interesting: with Process Explorer I found that pause() leaks semaphore handles as well as memory, so the flush probably forgets to clean up a semaphore object…

#13 Pingback By Solving a Matlab hang problem | Undocumented Matlab On February 6, 2013 @ 11:01 am

[…] a reader’s comment yesterday happened on the same page where I explained the problem and solution […]

#14 Pingback By Take a break, have a pause() | matlabideas On May 18, 2013 @ 7:54 am

[…] time ago my colleague showed me an article from Undocumented MATLAB that argues in favour of the Java Thread.sleep() function instead of the MATLAB pause() […]

#15 Comment By Sometalk On August 16, 2018 @ 12:53 pm

Have you rerun this benchmark more recently? I wonder if there have been any improvements in this space.

#16 Comment By Yair Altman On August 16, 2018 @ 2:35 pm

In recent Matlab releases, Matlab’s pause is no less (sometimes even more) accurate than Java’s Thread.sleep, with a consistent mean inaccuracy (overhead) of 0.1-0.2 ms and max inaccuracy of ~1ms, regardless of the pause duration. These values depend of course on the specific OS and CPU, so YMMV.

Article printed from Undocumented Matlab: https://undocumentedmatlab.com

URL to article: https://undocumentedmatlab.com/blog/pause-for-the-better

URLs in this post:

[1] Image: http://undocumentedmatlab.com/feed/

[2] email feed: http://undocumentedmatlab.com/subscribe_email.html

[3] commented: https://undocumentedmatlab.com/blog/waiting-for-asynchronous-events/#comment-105879

[4] Thread.sleep(): http://docs.oracle.com/javase/6/docs/api/java/lang/Thread.html#sleep(long)

[5] EDT: https://undocumentedmatlab.com/blog/matlab-and-the-event-dispatch-thread-edt/

[6] quite important: http://www.mathworks.com/matlabcentral/answers/7309

[7] Matlab-Java memory leaks, performance : https://undocumentedmatlab.com/blog/matlab-java-memory-leaks-performance

[8] File deletion memory leaks, performance : https://undocumentedmatlab.com/blog/file-deletion-memory-leaks-performance

[9] Converting Java vectors to Matlab arrays : https://undocumentedmatlab.com/blog/converting-java-vectors-to-matlab-arrays

[10] Expanding urlread capabilities : https://undocumentedmatlab.com/blog/expanding-urlreads-capabilities

[11] Solving an mput (FTP) hang problem : https://undocumentedmatlab.com/blog/solving-an-mput-ftp-hang-problem

[12] Using SQLite in Matlab : https://undocumentedmatlab.com/blog/using-sqlite-in-matlab

[13] : http://undocumentedmatlab.com/blog/matlab-and-the-event-dispatch-thread-edt/

[14] : http://www.mathworks.com/support/bugreports/819115

Copyright © Yair Altman - Undocumented Matlab. All rights reserved.