Why does MATLAB's permute not need extra memory?

Question

The permutation operation needs to output a different matrix to the output, it\'s not like reshape, where the data is not modified, permute does modify the

Answer 1

This is only a guess, as I don't really know what permute does under the hood.

1. Permuting of dimensions can always be done as a sequence of elementary permute operations, where" elementary" means interchanging only two dimensions. For example, permute(x, [4 1 2 3]) is equivalent to this sequence of elementary permute operations (the sequence is not unique):

   permute(..., [4 2 3 1]) %// interchange dims 1 and 4: we have dims [4 2 3 1]
   permute(..., [1 4 3 2]) %// interchange dims 2 and 4: we have dims [4 1 3 2]
   permute(..., [1 2 4 3]) %// interchange dims 3 and 4: we have dims [4 1 2 3]
   

2. Each of these elementary operations (interchanging two dimensions) is essentially a transpose along a given plane of the multidimensional array, performed repeatedly along all other dimensions.

3. Transposition can be done inline, requiring only a fixed amount of extra memory, independent of array size, or growing very slowly with array size.

Putting these three facts together shows that it is possible to do it without a significant amount of extra memory. This may not be the approach actually used by Matlab, though.

Answer 2

Your argument is flawed because the MATLAB memory profiler is not telling you the truth!

The permute method in fact does create a second copy of the matrix with the data permuted and returns it...

I just tried this myself:

• In Windows 10, I opened the "task manager" on the "performance" tab with the "memory" graphs in view. I also set the "update speed" to "high" to get a finer time resolution.

• I only have 8 gigs of RAM on my laptop, so to avoid thrashing I modified your function as:

  function out = mtest()
      out = rand([1e3,5e2,5e2]);  % about 1.8 GB = 1e3*5e2*5e2*8/2^30
      out = permute(out, [3 2 1]);
  end
  

• I then ran the function simply as:

  %clear a
  a = mtest();
  

  and watched the memory usage; It went from 1.8 gigs in use, and rose to 5.2 then quickly down to 3.6 gigs. This confirms that a copy was created.

I also repeated the test under perfmon.exe which showed the same pattern:

you can see how at its peak the function reached twice as much memory usage as when it returned.

While this is not exactly the best way to profile memory usage (better use a proper memory profiler, something like Intel Inspector XE), it does show to some degree that permute is indeed not working in-place.