Is calling length() as needed slower than storing the value just once in a separate variable?

The question really is: are the dimensions of an array stored somewhere on the stack, or does the length() function perform some calculation everytime it is called? I can obviously store the length of some array dimension in a separate variable, and thus, only call length() once, and then just reference the variable wherever I need this integer value. But, sometimes, the code just looks cleaner and clearer when I call length() everytime I need this value.

I am in a position where I am reinitializing a nested for loop for every outer for loop iteration, and I am using length() to define the nested loop's boundaries. But if length() is a function that takes some time everytime its called, it would obviously be more efficient to call length() just once and store its value.

[David Hill]

My understanding is yes, each time length() is called it executes the function.

[Christopher Wong]

Does this computation have a finite speed? For example, in C, whenever you want to know the size of some array, the value is returned instantaneously, since the compiler already knew this value from the start. I'm wondering if matlab sort of stores this value somewhere in a similar way, or if it actually tries to compute this value by some means.

[Stephen23]

"I'm wondering if matlab sort of stores this value somewhere in a similar way, or if it actually tries to compute this value by some means."

Both.... Search this forum for "JIT" and be prepared to do a lot of reading.

[Christopher Wong]

Thank you, gentlemen

Answer 1

[dpb]

Any computation has a finite speed...even memory access alone.

Builtin data types contain a knowledge of the dimensions allocated, yes (else't there would be no error that you just exceeded array bounds in indexing expressions).

I suspect whether the JIT compiler can cache the result of a length() call is minimal at best since one can always redimension silently in MATLAB it would be only verifiably static cases where could be possible and that's (I'm guessing) probably more expensive than the cost.

So, while this is conjecture (I looked a little on Yair's site to see if he had any background info on subject but couldn't find quickly), I think one can be assured that as David says, when you call length it is executed. functions are cached, I suspect the largest overhead with length is the determination of which method to call...try

which -all length

to see how many instantiations there are on your system--this is a fairly plain vanilla install with a limited number of toolboxen and there are 20-some associated with those few toolboxes besides the 10 or so built-in versions.

However, I would still suspect it is unlikely to be the bottleneck in any code of any real complexity unless you've truly got a million of 'em scattered around.

Like always, it's also premature to try to peephole optimize until you have profiled the code to find out where the peformance bottleneck(s) is/(are). You could eliminate 100% of a particular calculation but if that's only a small fraction of the total, you've still gained virtually nothing.

Write clearest code you can first, only if it is shown to be unsatisfactory in performance, then profile and work on those areas. Don't try to outguess...

[Stephen23]

The TMW blogs agree, e.g. "We recommend not writing specifically for the JIT since the JIT is constantly evolving. You should though keep in mind the general good MATLAB-coding practices..."

source: https://blogs.mathworks.com/loren/2008/06/25/speeding-up-matlab-applications

and make it clear that code should not be written around JIT enhancements: "Keep your code natural. Don't write unnatural code just to take advantage of this."

source: https://blogs.mathworks.com/loren/2007/03/22/in-place-operations-on-data/

I expect that it would be faster to obtain the value before the loop.

[Christopher Wong]

Thank you, gentlemen. I agree, it is probably, even if only infinitesimally, faster to obtain the array dimension before the loop.

@dpb this is great coding advice in general. I'm always subconsciously trying to balance friendly scripting and performance optimization whilst I write code, but perhaps the performance trade-off of this particular issue is too insignifcant. Or perhaps it isn't, which is where your advice has shone some new light on me - most performance improvements can be made with your gut, without taking any measurements. But this one I am truly unsure, and so, you're right, I shouldn't try to overguess this one, and just write the cleaner script in this case.

Very doubtful that I would notice any peformance decrease if I just called length as needed. Still, the information you guys provided is helpful as rules-of-thumb. In the future, if I find myself in a situation where I need to call length() dozens of times over, I should just call it once and store the value. Maybe it saves me 0.01s and it really isn't all that messy ;)

[dpb]

"I'm always subconsciously trying to balance friendly scripting and performance optimization whilst I write code"

Besides the TMW links Stephen provided, Yair has many hints and much to learn at <tips-for-accelerating-matlab-performance>

Answer 2

[Walter Roberson]

function test_speed
foo = zeros(randi(255),randi(255),randi(255));
f1 = @() length(foo);
Lfoo = length(foo);
f2 = @() Lfoo;
N = 256;
t1 = zeros(N,1);
t2 = zeros(N,1);
t3 = zeros(N,1);
t4 = zeros(N,1);

ws = warning('off','MATLAB:timeit:HighOverhead');
cleanme = onCleanup(@() warning(ws));

fprintf('testing length first time\n');
for K = 1 : N; t1(K) = timeit(f1,0); end
fprintf('testing stored length first time\n');
for K = 1 : N; t2(K) = timeit(f2,0); end
fprintf('testing length second time\n');
for K = 1 : N; t3(K) = timeit(f1,0); end
fprintf('testing stored length second time\n');
for K = 1 : N; t4(K) = timeit(f2,0); end

plot([t1,t2,t3,t4])
legend({'length', 'stored', 'length again', 'stored again'})

fprintf('mean length = %g %g\n', mean(t1), mean(t3));
fprintf('mean stored = %g %g\n', mean(t2), mean(t4));

end

You will not get the same results for a script! JIT for functions is different than JIT for a script!

You will not necessarily see the same results for the second run as for the first run! Historically, the first run of any timing test has been notably slower than the second run of the timing test, and that has been on a per line basis, not just a first-time overhead for the very first run. Historically, t3 and t4 would have been notably faster than t1 and t2, even though they invoke exactly the same code.

With time differences as small as these, you have to be very careful about exactly what you are timing.

[Walter Roberson]

I did't post numeric results because it will depend on your system!

[Christopher Wong]

Thank you, sir. All very helpful and insightful nonetheless!