How to avoid allocating memory for the returned value each time a function is called

I have a function that returns a large vector and is called multiple times, with some logic going on between calls that makes vectorization not an option.

An example of the function is

function a=f(X,i)

a=zeros(size(X,1),1);
a(:)=X(:,i);  

end

and I am doing

for i=1:n  a=f(X,i); end

When profiling this (size(X,1)=5.10^5, n=100 ) times are 0.12s for the zeros line and 0.22s for a(:)=X(:,i) the second line. As expected memory is allocated at each call of f in the 'zeros' line.

To get rid of that line and its 0.12s, I thought of allocating the returned value just once, and passing it in as return space each time to an appropriate function g like so:

function a=g(X,i,a)
       a(:)=X(:,i);  
end

and doing

    a=zeros(m,1);
   for i=1:n    a=g(X,i,a);    end

What is surprising to me is that profiling inside g still shows memory being allocated in the same amounts at the a(:)=X(:,i); line, and the time taken is very much like 0.12+0.22s..

1)Is this just "lazy copy on write" because I am writing into a? 2)Going forward, what are the 开发者_JAVA百科options? -a global variable for a (messy..)? -writing a matrix handle class (must I really?) (The nested function way means some heavy redesigning to make a nesting function to which X is known (the matrix A with notations from that answer)..)

Perhaps this is a bit tangential to your question, but if this is a performance critical application, I think a good way to go is to rewrite your function as a mex file. Here is a quote from http://www.mathworks.com/support/tech-notes/1600/1605.html#intro,

The main reasons to write a MEX-file are:... Speed; you can rewrite bottleneck computations (like for-loops) as a MEX-file for efficiency.

If you are not familiar with mex files, the link above should get you started. Converting your existing function to C/C++ should not be overly difficult. The yprime.c example included with MATLAB is similar to what you're trying to do, since it is iteratively being called to calculate the derivatives inside ode45, etc.