I have recently discussed undocumented features in Matlab’s built-in profiler. Another tool often used for ad-hoc performance profiling of Matlab code are the built-in duo functions tic and toc:
>> tic; magic(500); toc
Elapsed time is 0.474647 seconds.
Both tic and toc are documented functions, but they contain an undocumented option (at least until R2008b – see history below) that enables nested clocking. The problem that is solved using this undocumented option is that if we try to use tic/toc in external function parentFcn and also in the internal function childFcn, we get unexpected results. This happens because our childFcn’s invocation of tic has reset the clock and so parentFcn’s clock is now obviously incorrect:
function parentFcn % Start clocking tic; % Do something long... m1 = magic(1500); % Call nested function toc1 = childFcn; % Present clock timing toc2 = toc; fprintf('Elapsed time for childFcn: %0.3f secs\n',toc1) fprintf('Elapsed time for parentFcn: %0.3f secs\n',toc2) % Nested function with separate clocking function t = childFcn tic; m = magic(800); t = toc; end % childFcn end % parentFcn
>> parentFcn
Elapsed time for childFcn: 1.063 secs
Elapsed time for parentFcn: 1.068 secs
The solution: use a separate handle for each clock. The format is very simple:
>> t = tic;
>> toc(t)
This format ensures independent clocking of the clocks. Clockings can now be safely nested and even partial overlap is possible:
function parentFcn % Start clocking t1 = tic; % Do something long... m1 = magic(1500); % Call nested function toc1 = childFcn; % Present clock timing toc2 = toc(t1); fprintf('Elapsed time for childFcn: %0.3f secs\n',toc1) fprintf('Elapsed time for parentFcn: %0.3f secs\n',toc2) % Nested function with separate clocking function t = childFcn tic; m = magic(800); t = toc; end % childFcn end % parentFcn
>> parentFcn
Elapsed time for childFcn: 1.123 secs
Elapsed time for parentFcn: 4.992 secs
For the record, this undocumented option was first presented by the MathWorks support team as an official workaround for the aforementioned problem. The solution was originally posted for Matlab R2006b, but actually the option was supported by Matlab versions at least as early as R14SP3 (7.1) – perhaps even earlier (I don’t have ready access to earlier versions). I do know that it was not supported on release R12 aka 6.0, but I don’t know whether it was introduced in 6.5, 7.0 or 7.1. This option has only been documented since R2008b, although it has existed in many earlier releases.
Now here’s a puzzle for all you undoc fans out there: toc has a really undocumented option of using an uninitialized uint64 value, rather than an actual tic handle. It seems that whichever value is passed will always result in the same result, but this result is uncorrelated to any possible event (start of Matlab, midnight etc.). It even works without any prior tic invocation! I would love to hear your thoughts on what you think this strange toc result might represent:
>> toc(uint64(1)) Elapsed time is 72825.947547 seconds. >> toc(uint64(1234)) Elapsed time is 72826.538296 seconds.
Related posts:
- cellfun – undocumented performance boost Matlab's built-in cellfun function has an undocumented option to significantly improve performance in some cases....
- ismembc – undocumented helper function Matlab has several undocumented internal helper functions that can be useful on their own in some cases. This post presents the ismembc function....
- Undocumented scatter plot behavior The scatter plot function has an undocumented behavior when plotting more than 100 points: it returns a single unified patch object handle, rather than a patch handle for each specific point as it returns with 100 or less points....
- uiundo – Matlab’s undocumented undo/redo manager The built-in uiundo function provides easy yet undocumented access to Matlab's powerful undo/redo functionality. This article explains its usage....
- Undocumented profiler options The Matlab profiler has some undocumented options that facilitate debugging memory bottlenecks and JIT (Just-In-Time Java compilation) problems....
- Undocumented mouse pointer functions Matlab contains several well-documented functions and properties for the mouse pointer. However, some very-useful functions have remained undocumented and unsupported. This post details their usage....
Tags: performance, pure Matlab, Undocumented feature
Categories: Low risk of breaking in future versions, Stock Matlab function, Undocumented feature
This entry was posted
on Friday, May 22nd, 2009 at 6:12 am PST
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.

I believe the undocumented toc(uint64(1)) option is connected to the last time you restarted your computer. I ran this function twice. Once before I restarted and once after. The number before restart was the equivalent to about 72 hours, the number after was about 3 minutes.
You must be right Jason – this also correlates with the number I posted above. Good catch!
It is equal to the uptime of my computer.
The value returned by tic is not a handle. It is just a counter with some native time step.
On my computer, one tic is 6.9836e-008 seconds, according to my measurements. This internal counter starts at 0 when the computer starts.
I think that the uint64 number returned by tic is the number of microseconds after the system started. It is also the most straightforward way to implement such tic/toc mechanism.
The usual behavior of other functions, instead, made me initially think of the value being some sort of handle to internal data, which is probably not.
This is confirmed by a couple of tests (at least under linux):
>> a=tic; pause(1); b=tic;
>> disp(double(b)-double(a))
1000624
>> a=tic; pause(2); b=tic;
>> disp(double(b)-double(a))
2000627
… and also:
>> a=tic; pause(1); toc(uint64(double(a)+1))
Elapsed time is 1.000410 seconds.
A partly unrelated note:
>> uint64(1)+uint64(2)
??? Undefined function or method ‘plus’ for input arguments of type ‘uint64′.
Why?!?
It is not the number of microseconds on Windows. It has a higher resolution than that.
tic appears to return the number of microseconds since the epoch, at least on my r2007b install on 64 bit linux:
>> [a,retv_pre] = system(‘date +”%s”’);ticv = tic();[a,retv_post] = system(‘date +”%s”’);retv_avg = 0.5 * (str2num(retv_pre) + str2num(retv_post));retv_avg – (double(ticv) / 1e6)
ans =
-0.5501
TIC/TOC has had this option for a long time. I seem to remember it in the MATLAB 5.3 days, but I might be wrong.
TIC sets a local persistent variable to the current time. TOC returns the difference between that time and the current time. The value T=TIC just returns the current time, without resetting the local variable. TOC(T) then returns the difference between T and the current time. If T is larger than the current time, it uses the local variable. That is, it ignores its input. How the “current time” is defined could depend on the system, though. I wouldn’t count on it being the time since the computer last rebooted.
Oh, I should have checked earlier. I’m just now looking at HELP TIC and HELP TOC. This feature is documented in R2009a.