Why do I obtain different performance when I execute equivalent code in MATLAB 7.3 (R2006b)?

I obtain different performance when I execute equivalent code in MATLAB 7.3 (R2006b). When I operate on scalar variables that are constructed explicitly as such (i.e. operate on dtemp = d(1)), I obtain better performance than when I operate on data that is not explicitly defined as scalar (i.e. dtemp = d, where d = sum(vector)). This can be seen when I run the MATLAB Profiler on the two following pieces of code.

1. Fast code:

average=0;

for ii = 1:2000000

Dima = (ima(x-f:x+f, y-f:y+f) - ima(nx-f:nx+f, ny-f:ny+f));

Dima = Dima(:);

Dima = Dima.^2;

d = sum(Dima);

dtemp = d(1);

w = exp(-dtemp * acumh);

if(w>0), wmax = w; end;

average = average + w*ima(nx,ny);

end

2. Slow code

average=0;

for ii = 1:2000000

Dima = (ima(x-f:x+f, y-f:y+f) - ima(nx-f:nx+f, ny-f:ny+f));

Dima = Dima(:);

Dima = Dima.^2;

d = sum(Dima);

dtemp = d;

w = exp(-dtemp * acumh);

if(w>0), wmax = w; end;

average = average + w*ima(nx,ny);

end

The only difference between the two pieces of code above is where 'dtemp' is created. However, the lines that come after this assignment significantly longer to execute.

Answer 1

[MathWorks Support Team]

When compiling a section of code, the Just-in-Time compilation (JIT) uses flow analysis to assign types and shapes to variables.

There is a limitation that a given variable can only have one type/shape combination in a compiled segment. In order to maximize the amount of code in a compiled segment, the JIT will generalize the type/shape of a variable.

For example, if a variable starts out as a matrix, and is assigned a column value, the shape will still be analyzed as 'matrix'. That is what is happening in the example code. In the for loop, the shape of the variable 'Dima' starts out as matrix, and even though the assignment "Dima = Dima(:)" turns it into a column, the analyzed shape is still 'matrix'. The analyzed shape of "sum()" called on a matrix is 'column', so the variable 'd' gets analyzed to have a nonscalar shape. By assigning d(1) to a different variable, that new variable is forced to be scalar, and the JIT can generate better code.

The workaround for this limitation is to introduce a new variable when using indexing to reduce the shape of an array (i.e. matrix -> vector -> scalar). That is basically what the faster version of the code is doing, or you could use:

Dima = (ima(x-f:x+f, y-f:y+f) - ima(nx-f:nx+f, ny-f:ny+f));

Dima_temp = Dima(:);

Dima_temp = Dima_temp.^2;

d = sum(Dima_temp);

For this specific example, the following would also work (Dima(:) is being computed, but not assigned back to Dima, so it will be analyzed as a column, and d should be scalar):

Dima = (ima(x-f:x+f, y-f:y+f) - ima(nx-f:nx+f, ny-f:ny+f));

Dima = Dima.^2;

d = sum(Dima(:));

Note, however, that since the just-in-time compiler (JIT) is evolving, optimizations that you make to the code regarding this particular issue may not be useful in future releases of MATLAB. This is why we abstain from recommending code optimizations based on the current version of the JIT.