Pause(n) vs timer. Which is better?

So I'm trying to show a plot of time dependent data as if it is taken in real time. The issue with using the pause(n) function within a for-loop is that the loop performance deteriorates, and plotting the functions drastically slows down. Can this be remedied with a timer? And how could I achieve the same outcome as the code below using a timer?

Here's the code:

% inputs
t = 1:0.05:25;

% time-dependent functions
sin_t = sin(t);
cos_t = cos(t);

% loop for time-dependent measurements
n = numel(t)
figure, xlim([min(t) max(t)]), ylim([-2 2]);

hold on

for i = 1:n
     plot (t(1:i), sin_t(1:i));
     plot (t(1:i), cos_t(1:i));
     pause(0.01);
end

hold off

[kjetil87]

you could offcourse use timers, but you could also gain something on not replotting the same data.

you could for instance try with:

for i=1:n-1
plot( t(1+i-1:i+1) , sin_t(1+i-1:i+1) )
...

then you wont use unnecessary time plotting stuff that is already in your plot.

[Sean de Wolski]

@kjetil: an even bigger improvement is to not call PLOT again. Calling plot requires creating an additional line which has its own overhead. It's more efficient to change the data of the existing line object like I did below. NOTE, you could do this in a for-loop as well as in the timer callback.

Answer 1

[Sean de Wolski]

I always recommend using timers. They require a little bit more effort to become familar with but are much more powerful. They also emulate a multithreaded environment so you can continue to use the command line while they are running. Here is your example with a timer.

function timerEx
% inputs
t = 1:0.05:25;
% time-dependent functions
sin_t = sin(t);
cos_t = cos(t);
% loop for time-dependent measurements
n = numel(t);
figure, xlim([min(t) max(t)]), ylim([-2 2]);
hold on

%Plot first point, store handles so we can update the data later.
h(1) = plot (t(1), sin_t(1));
h(2) = plot (t(1), cos_t(1));

%Build timer
T = timer('Period',0.01,... %period
          'ExecutionMode','fixedRate',... %{singleShot,fixedRate,fixedSpacing,fixedDelay}
          'BusyMode','drop',... %{drop, error, queue}
          'TasksToExecute',n-1,...          
          'StartDelay',0,...
          'TimerFcn',@tcb,...
          'StartFcn',[],...
          'StopFcn',[],...
          'ErrorFcn',[]);

% Start it      
start(T);

      %Nested function!  Has access to variables in above workspace
      function tcb(src,evt)
          %What task are we on?  Use this instead of for-loop variable ii
          taskEx = get(src,'TasksExecuted');

          %Update the x and y data.
          set(h(1),'XData',t(1:taskEx),'YData',sin_t(1:taskEx));
          set(h(2),'XData',t(1:taskEx),'YData',cos_t(1:taskEx));
          drawnow; %force event queue flush
      end
  end

[Jan]

+1.

[Caleb]

It's still extremely laggy, but that must be my system more than anything else.

[Sean de Wolski]

One thing you could consider would be reducing the number of iterations and increasing the time between them. 24hz is typically the the threshold for smooth motion so setting the period to 0.04 will be faster than this but will reduce the number of plot updates by 4x.

[Caleb]

Is it possible to vary the period during execution? Like the user could speed up or slow down the graphs?

[Sean de Wolski]

Not trivially. I did write an answer on here a long time ago that discussed how to do that. Essentially each timer would fire off another SingleShot timer with a StartDelay equal to the intermediate period. Frankly, for that I would just recommend a for-loop.

[Jan]

@Caleb: If the varied speeds have a common divisor, this can work by starting a timer with a higher frequency and let the timer callback run every 2nd, 3rd, ... call only:

function TimerCallback(TimerH, EventData)
UD = get(TimerH, 'UserData');
if rem(get(TimerH, 'TasksExecuted'), UD.Rate) ~= 0
  return;
end

Now an external function can change the Rate field in the timer's UserData.

It would be a bad idea to use a timer frequency of 1/100th second, because this would exhaust the resources. But if you want to run the timer every 0.25, 0.5, 0.75 etc seconds, the above shown method would work sufficient.

[Daniel Shub]

@sean timers emulated a multithreaded environment which is why I always recommend loops. MATLAB doesn't provide enough support to be multithreaded.

As for the rate, your monitor is probably running at a rate of 60 Hz, so anything faster than that is wasted. If you really want real time you need to plot with low level OpenGL calls. There are a number of toolboxes that make it less difficult. I would play around with the speed until you are happy. My guess is 10 Hz would be plenty fast.

[Sean de Wolski]

@Daniel, Why not?

You could use the wait() method of the timer to force it to wait.

[Daniel Shub]

I like a loop better than a timer for two reasons. First, the error handling of callbacks is really bad in that an error in a callback doesn't stop the main thread. Second, timer callbacks can interrupt between any two "commands", even if those commands need to occur close together in time or leave an object in an unstable state. With a 10ms period and a callback that operates on graphic objects, it doesn't seem like there will be enough time for a second thread to be useful.