Undocumented profiler options

The Matlab profiler is a powerful tool for debugging performance-related issues in Matlab applications. However, it also has some undocumented options that facilitate other forms of debugging, namely memory bottlenecks and JIT (Just-In-Time compilation) problems.

To turn on memory stats in the profile report, run this (only once is necessary – will be remembered for future profiling runs):

profile -memory on;
profile('-memory','on'); % an alternative

To turn on JIT information, run this (again, only once is necessary, prior to profile report):

setpref('profiler','showJitLines',1);

You will then see additional JIT and memory (allocated, freed and peak) information displayed in the profile report, as well as the options to sort by allocated, freed and peak memory:

Profile report with memory & JIT info

For those interested, the references to these two options appear within the code of profview.m (line 1199 on R2007b), for the JIT option:

showJitLines = getpref('profiler','showJitLines',false);

…and profile.m (lines 163-165 on R2007b), for the memory option:

if memory ~= -1
callstats('memory', memory);
end

Note that there appears to be two undocumented additional memory-related options in profile.m (lines 311-312):

However, ‘-nomemory’ appears to simply turn the memory stats collection off, and ‘-callmemory’ is not recognized because of a bug in line 349, which looks for ‘callnomemory’…:

case 'callnomemory'% should be 'callmemory'
memory = 2;

When this bug is fixed, we see that we get only partial memory information, so the ‘-callmemory’ option is really not useful – use ‘-memory’ instead.

Addendum (Jan 31, 2011): JIT information has been removed in Matlab 7.12 (R2011a). I assume that this was done so that programmers will not attempt to depend on JITC functionality in their code (see Scott’s comment below). It’s a good thing that the memory options remain, since these are quite useful in profiling memory-related bottlenecks.

23 Responses to Undocumented profiler options

Thanks for another interesting post. I’d like to share a couple of comments:

– We would love feedback on the memory profiling feature. We know there’s a lot of interest in tools to help figure out where and how memory is chewed up in code, but it turns out to be not so obvious as to what information to present and how. I’ll keep an eye out here for comments, or readers can feel free to email me directly. My address is on my MATLAB Central page.

– I would advise a bit of caution when working with the JIT profiler results. We turned them off after MATLAB 6.5 primarily because the JIT was such a moving target (changing every release) that we really didn’t want to encourage users to code against it. That being said, your readers all know the standard warning that comes with your posts – so have fun poking around!!

It doesn’t work for me in 2007B, OS X 10.5. It gives me the following error from callstats.m: “Support for memory tracking is not available with the current memory manager.

This is unfortunate, because lack of memory profiling is one of Matlab’s biggest performance gaps. As someone who works with massive neuroimaging data sets every day, good memory use is more important to me than CPU performance. Shaving an hour or two off an analysis is nice, but using too much memory means my analysis won’t even finish.

As an ex-professional programmer, I’d seriously considered making and selling something like this as an add-on if I wasn’t in grad school.

Maybe in that far-off utopia of infinite funding, I can convince my advisors to buy all the necessary copies of later matlab versions.

@Matthew – please read Scott Hirsch’s comment above. Scott is the Matlab product manager at MathWorks and says that they “would love feedback on the memory profiling feature”. Perhaps you could contact him via the attached link and explain your use-case. There might be a workaround for your Matlab version/platform. Even if not, it might benefit other users who have similar issues. If you learn anything new, please do post it here.

Hi Yair, Can you explain a little more how you used the profiler to detect leaks? I’m working on a continuously running software (always open, but runs a set of functions/methods every minute or so) that seems to creep up in memory over time. I ran the profiler while executing my code and am trying to understand what I’m looking at. I see allocated, freed, self, and peak memory, but don’t know how that translates to memory growth over time. Any help would be appreciated!

@Andrew – it should be relatively easy to see where allocated>freed: when there are no leaks, these two should have exactly the same value.

You could also use non-Matlab tools (e.g., Process Explorer for memory leaks or GDIView for GDI handle leaks — both of them for Windows).

Note in advance that hunting down memory leaks in Matlab is very difficult, due to the lack of good monitoring tools (AFAIK).

If you or anyone else find any leaks, please report them here or directly to me. I know for a fact that MathWorks’ dev team are very interested in such inputs — whatever will be reported to me I will pass on to them for fixing.

Hi Yair, That’s what I figured, but I thought I would ask for clarification anyway. Thanks so much for your quick response and wealth of knowledge! It seems a bit strange. I can run the same set of functions with the same inputs, but the profiler comes back with different results. And I’ll need to determine if it’s my code or Matlab itself causing the memory growth… Well, I will certainly let you know what I can come up with. Thanks again! ~Andrew

Hi dear Yair i want to know differences between peak memory, self memory, allocated memory and freed memory while we are using Memory monitoring using profiler. i google it but it seems no one knows about the issue! thanks in advance.

@Jabbar – I believe that these are an approximate description of the various reported values:

* Peak memory is the maximal amount of allocated memory during the execution of the profiled line/function. * Allocated memory is the total amount of memory allocated during the execution. Note that it is a cumulative amount, meaning that if you have an allocation of 1KB in a loop that runs 50 times, you’ll see a 50KB value. * Freed memory is the total amount of memory de-allocated during the execution. This too is a cumulative amount. * Self memory is the memory used by the profiled line/function, which is not deallocated (and therefore not included in the “Freed memory” value).

Note that these are speculations: The exact definition of what is reported under which category is internal to Matlab and is currently unknown.

Recent Comments

Yair Altman (1 day 9 hours ago): yes, this post was originally posted in 2011, more than 5 years ago – Matlab has changed a lot since then, including an entirely revised graphics system (HG2). The current...

Andrew (1 day 9 hours ago): I figured it out…actually found it elsewhere but then realized it is mentioned in this original post as well. You can still use getcursorinfo(dcmObject) to get a list of all...

Andrew (1 day 10 hours ago): Hello, Did MATLAB recently change the syntax to this? I am trying to get access to the current list of datacursors programatically, but nothing I have tried seems to work. >>...

Yair Altman (2 days 12 hours ago): @Alex – there is no immediate answer. If you want me to look at your specific code, then email me (altmany at gmail) for a dedicated consulting session.

Yair Altman (2 days 12 hours ago): Perhaps you have an outdated version of export_fig. Try to download the latest version from https://github.com/altmany/exp ort_fig

mimi sam (2 days 13 hours ago): I have “GPL Ghostscript” installed on my PC and I get this : In export_fig at 660 export_fig error. Please ensure: that you are using the latest version of export_fig...

Jaap Nienhuis (3 days 7 hours ago): I frequently make images in Matlab. Is it possible, to render the raster component of the image as a bitmap (image in illustrator) and to render the axes labels etc as vector...

Yair Altman (6 days 9 hours ago): @DavidB + @Guillaume + @TheBlackCat – if I remember correctly, my client wanted the code to continue processing only when the 2 inputs were both vectors, although possibly...

David B (6 days 16 hours ago): @TheBlackCat From the limited information we have available we are assuming the data is a vector. If that is the case then I think something like this code snippet would work nicely...

TheBlackCat (7 days 9 hours ago): It is hard to say without seeing more code. It may very well be that the data can only come in a few formats, so transposing it is the correct thing to do.

Guillaume (7 days 10 hours ago): Well, presumably, the code is operating on vectors, so the alternative could be dataA(:) + dataB(:) But really, the proper alternative would have been to find out why the data...