# More about automatic array growth improvements in MATLAB R2011a3

Posted by Steve Eddins,

Earlier this week I wrote about the improvements in automatic array growth in MATLAB R2011a. The posted comments made me realize that I should give a few more details so that you can understand all the circumstances under which this improvement might benefit you.

To illustrate the improvement with a slightly different code fragment than the for-loop I used the other day:

  y = [];
while not_done_yet()
if some_condition()
y(end+1) = next_value();
end
end

We don't know in advance how big y is going to be, so it's harder to preallocate space for it. It would really be nice if I could just write the above code and let MATLAB handle all the boring details automatically efficiently.

Well, prior to R2011a, MATLAB would all handle all the boring details of array growth automatically but not efficiently. Now it also handles array growth efficiently.

Here are some more details you might find helpful.

• Automatic array growth works best for vectors (of any orientation) or when growing along the last dimension of a multidimensional array.
• Automatic array growth works for all numeric types as well as cell arrays and object arrays.
• The optimization also helps when you are adding a large number of fields to a struct.

Also, for numeric array types, certain kinds of growth by concatenation are supported. Specifically, the case where a numeric array is concatenated with itself is now optimized:

   x = [];
for k = 1:n
x = [x k];
end

One blog reader wondered if this optimization means that there might be situations where some very large vectors or arrays might be using twice as memory as necessary.

The answer is no, not really. MATLAB uses a smarter heuristic than simply doubling the allocated memory space whenever more is needed, so for large arrays the worst-case memory "overallocation" is much less than a factor of two. I don't intend to get into further details here because (a) I don't know them, and (b) I expect that we will continue to tune the heuristic and other aspects of automatic array growth with future releases.

I'll conclude by repeating my recommendation from earlier this week. If it's trivial to precalculate the final size of a growing array before entering a loop, then by all means use preallocation. It's the fastest way to go. But if it's not trivial, and if the pattern of growth matches one of the cases described above, then you can consider just letting MATLAB handle the array growth for you without worrying about bad performance scaling.

Get the MATLAB code

Published with MATLAB® 7.12

Hi Steve,

I have just read your 2 last articles . When I read “MATLAB R2011a performs much better than previous MATLAB versions when performing repeated array growth in a loop. “
, I thought this argument is enough to convince any reluctant MATLAB user to upgrade.

Just one/two questions:
Where can I find “officially” this improvement?
Is it written somewhere in TMW website?

Thanks

Steve replied on : 2 of 3

Aurélien—It is mentioned in the R2011a release notes, but the details are not described.

Ok I understand now what I missed this feature!

The Release Notes just say :

"Growing Arrays Is Faster
This release improves the performance of growing an array in the trailing dimension if that array has not been preallocated."


http://www.mathworks.com/help/techdoc/rn/bstrgub-1.html#bsy83rt-1

I confirm the details are not described!!!

It makes me think to the bug report 387311 which says “Axes XLim,YLim and ZLim properties do not preserve precision of input data.”
( direct link : http://www.mathworks.com/support/bugreports/387311 )
and there is no description , I mean no matlab code to understand what the issue is, how we can reproduce the bug.

Nevermind , the most important thing is taht R2011a is faster to grow arrays ;)

Have a nice we

Note : If I have time I will use the link to the BR387311 to provide my feedback and to help you improve this bug Report!

Aurélien

These postings are the author's and don't necessarily represent the opinions of MathWorks.