But I appreciate that you are willing to consider this. Would be great if this comes as part of Matlab soon.

Also I would like to add more to this since the same improvement needs to be done with field values of structures and cell arrays (copies made in those cases as well, like object properties).

We will consider this and some related ideas as optimizations in the future. Thanks for you thoughts.

One less beautiful thing you could do for now is to get the property in a temp variable, set the property to [], make the call and set it back as in:

  obj = DataWrapper( rand( 2, 3) );
  data = obj.Data; % no copy b/c of copy-on-write
  obj.Data = [];
  data = my_inplace_func( data);
  obj.Data = data;

–Loren

I understand how the inplace technique works and it works fine given that I work within functions and with variables in Matlab( I checked that it works fine using the secret option of format command :)).

The problem I face( may be I’m failing to understand something) is with achieving the same behaviour with object properties. In my understanding Matlab object properties are no different from normal variables in Matlab’s perspective. If I pass a property of an object to an inplace function there is a copy being made and the operation is not done inplace.

The following is the sample I tried

% DataWrapper.m
classdef DataWrapper < handle
properties
Data
end

methods
function obj = DataWrapper( data )
obj.Data = data;
end
end
end

% my_inplace_func
function in_data = my_inplace_func( in_data )
in_data = sin( in_data .* 2 );
end

% my_inplace_test with normal variables. No extra copies
% made. ( The nice case ).
function my_inplace_test()
data = rand( 2, 3);
data = my_inplace_func( data);
end

% my_inplace_test with object properties. Extra copy is
% being made here. Would be great if you tell me why so.
function my_inplace_test()
obj = DataWrapper( rand( 2, 3) );
obj.Data = my_inplace_func( obj.Data);
end

Or is this a bug or a feature to be implemented in future as part of the JIT?

Would be great if you can share some information on this because I use large data arrays and this problem is really stopping me to move to object oriented programming.

It’s true you can represent the eigenvalues in a vector, but if you look at the help and how they get used, you often need them in a matrix to do various matrix multiplications and other operations.

–loren

[V,D]=eig(H)

D is a n*n diagonal matrix!

it is absolutely stupid!

D can be a n*1 vector, that would save a lot of memory!

Version does matter, but it only gets better in newer versions. There was a time when even with the same input and output names, copies were always made.

–Loren

I’m running through some functions I use often, making sure the output and input argument names are the same… :)

Perhaps you have more memory or swap space than me. On my machine, I run out of memory at that point. MATLAB has always had SOME inplace memory optimizations. They’ve just gotten better and more sophisticated over time.

–Loren

I don’t understand why, in inplaceTest, you say “if we changed this next call to assign output to a new LHS, we get an error”. In your example you don’t run y = myfuncIP(x). I seem to be able (R2009b) to do that. It would be awkward if a function that can compute in-place always needs the output argument to be the same as the input argument! The beauty of these in-place functions is that you can just change the variable name of the output argument in your old functions and get a nice speed and memory gain, while keeping perfect backward compatibility. But could this lead to problems in R2007a if the function is called with a different LHS argument?

I believe the API to do that is not documented or supported so could change in the future. But it is certainly something you could try.

–Loren