- create variables on the fly using eval or assignin
- use clear to remove variables from the table
- redefine the type of variables
A school boy Q? about the complexity of variable/symbol names.
3 views (last 30 days)
Show older comments
To recap;
Whilst comenting on a question, I asked " Does the length and complexity of variable names make any difference to a program compiling or a function running. "
Jan Simon kindly replyed " A school boy solution for the question about the complexity of symbols: Try it. Simply measure the time using TIC/TOC. But the question is too important to be hidden in the comments of another question. "
Well I did, I ran this;
function vShortOut = vShort(vSin)
%to test the length of variable names
tic
x = 1;
while x < 100000000
ab = vSin;
abyz = ab*ab;
abyz = abyz^10;
vShortOut = abyz;
x = x + 1;
end
toc
I also created the corresponding vLong, where ab was the complete alphabet and abyz was double alphabet. My result are;
while x < 1000000
vShort(2) - Elapsed time is 0.022960 seconds.
vLong(2) - Elapsed time is 0.027503 seconds.
vLong(2) - Elapsed time is 0.026545 seconds.
while x < 10000000
vShort(2) - Elapsed time is 2.148615 seconds.
vShort(2) - Elapsed time is 2.122362 seconds.
vShort(2) - Elapsed time is 2.115379 seconds.
vLong(2) - Elapsed time is 2.089561 seconds.
vLong(2) - Elapsed time is 2.074754 seconds.
vLong(2) - Elapsed time is 2.060859 seconds.
while x < 100000000
vShort(2) - Elapsed time is 20.904584 seconds.
vShort(2) - Elapsed time is 21.067507 seconds.
vShort(2) - Elapsed time is 20.979640 seconds.
vLong(2) - Elapsed time is 21.135573 seconds.
vLong(2) - Elapsed time is 21.064247 seconds.
vLong(2) - Elapsed time is 21.089929 seconds.
My conclusion is, that on my machine (year old quad core) running this function and variable length makes little or no difference. I noticed that watching processor performance in task manager when the while loop was in the 100's and 1000's, a system process or mouse movement could skew my ans sufficiently to make this test incomparable.
So my question still stands because logic tells me that when running an un-compiled function like this it has to make a difference, the processor has to read and find the variable. The longer the variable the more the processor has to read. Now for a compiled language like c/c++, that recently started learning also, the variable length should only effect (in theory/logic) the compile time not run time. I assume/hope that the compiler will reduce variable names to a short symbol or even memory pointers.
I asked this because I was being told off about ambiguous variable names and it got me thinking.
Please correct me where I am wrong.
Regards,
AD
0 Comments
Accepted Answer
Jan
on 26 Oct 2011
Matlab code is interpreted, when a function (or script) is loaded into memory. This happens when the function is called the first time in a Matlab session. A reloading is triggered by clear <funcname> or changing the function file during the command prompt is active. During the execution, the code is not interpreted again (execptions are explained later).
"Interpretation" means, beside other things, that a lookup table is created for names and array pointers of the variables. This is more expensive for longer names. During execution, Matlab accesses the array pointers directly and the lengths of the names do not matter anymore.
But you can impede the efficient access of this static table by modifying it dynamically:
Some examples (Win7, 2011b/64, Core2Duo):
function f1 % Reference function
tic;
a = 1;
b = 2;
for i = 1:1e7
b = a + b;
end
toc
% >> 0.049 sec
function f2 % Long names, no significant difference
tic;
aaaaaaaaaa = 1;
bbbbbbbbbb = 2;
for i = 1:1e7
bbbbbbbbbb = aaaaaaaaaa + bbbbbbbbbb;
end
toc
% >> 0.050 sec
function f3 % Disable efficient lookup table by EVAL
tic;
a = 1;
b = 2;
for i = 1:1e7
b = a + eval('b');
end
toc
% >> 38.43 sec
function f4 % Disable efficient lookup table by CLEAR
tic;
a = 1;
b = 2;
for i = 1:1e7
c = a + b;
b = c;
clear('c');
end
toc
% >> 59.61 sec
function f5 % Disable efficient lookup table by change of type
tic;
a = 1;
b = 2;
c = uint64(1);
for i = 1:1e7
b = c;
b = a + i;
end
toc
% >> 19.73 sec
function f6 % For comparison with f5
tic;
a = 1;
b = 2;
c = 1; % This means: double(1)
for i = 1:1e7
b = c;
b = a + i;
end
toc
% >> 0.0121 sec
Finally I agree with Jason: The runtime is just one part of the total solution. Too short names increase the time needed for programming, debugging and maintenance. You can keep the overview in a function with 4 variables with a single character as name. But only acrobats can do this for 16 variables. Programming, debugging and maintenance suffers from to short names for variabels
1 Comment
Walter Roberson
on 26 Oct 2011
If I recall correctly, scripts were supposedly not pre-parsed before R2010B. This cannot have been completely true, though, as scripts with major syntax errors were rejected upon startup of the script, not at the time the syntax error would have been reached in execution.
The timing discrepancies that used to show up for putting several commands on one line (in a script) vs putting them on distinct lines, implied that scripts were indeed not being fully parsed to p-code. Especially as it was the multi-line version that was faster: the multi-line would have more overhead for keeping track of current line number (for error procedure / debugging purposes), so if full parsing was done one would have expected the single line version to be at least as fast.
That was then and this is now... Except, of course, for those of us who are still using the older versions.
More Answers (2)
Daniel Shub
on 26 Oct 2011
MATLAB has some tricky JIT acceleration which I am guessing handles this. Your code only calls the function once, so MATLAB only has to find the variables once. You could move the while loop outside the function to see the function overhead. If you did this, you could also add a clear functions and make MATLAB reload the function on every loop. Finally you could also start MATLAB with the JIT turned off.
2 Comments
Jason Ross
on 26 Oct 2011
A bit of a personal rant follows:
Execution time is only one aspect of coding, programming and software development. Other important aspects include
- Debugging
- Maintenance
- Testing
- Addition of new features
- Documentation
- Sharing with others (Code reviews, publishing APIs, etc)
- Re-use in other programs
When you have ambiguous names, it becomes extremely difficult to read the code to figure out what the original intent was when the code is modified, even if the modifier is the same person revisiting the code 6+ months later!
Some studies I've seen have indicated that it's very common for code to be touched 10-15 times after initial implementation for one reason or another, and therefore the maintenance aspect comes to dominate the costs of maintaining the code.
I'd also offer that worrying about variable name length can be a sort of "pre-optimization", and your time would be better spent finding the bottlenecks in the design and attempting to optimize those first.
See Also
Categories
Find more on Scope Variables and Generate Names in Help Center and File Exchange
Products
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!