Is there anything to be gained memorywise and speedwise by having shorter variable-names in a language like python?
And if so, what kind of situations would it be reasonable to consider this?
Note
I'm in no way advocating short variable names, I'm just wondering, please (re)read the question.
Note 2 Please, I do understand the value of descriptive variable names. I've looked at enough code to prefer descriptive names over shorter names, and understand the value of it. A plain No doesn't really help.
Names to AvoidIt's almost always best to avoid single-letter variable names, which are not unique enough to help the reader associate a meaning with the name. This increases the mental tax on the reader and makes it harder to understand what the program is doing.
It is an open research issue whether some programmers prefer shorter identifiers because they are easier to type, or think up, than longer identifiers, or because in many situations a longer identifier simply clutters the visible code and provides no perceived additional benefit.
Variable name will have absolutely no influence at runtime, and totally negligible at compile time. But bad names will inevitably lead to bad performance because nobody understand the code and it ends up in a stack of hack one on top of another, making things worse each time.
The variable's name represents what information the variable contains. They are called variables because the represented information can change but the operations on the variable remain the same. In general, a program should be written with "Symbolic" notation, such that a statement is always true symbolically.
No. No. No. No. No.
Use readable names, not short names. The performance difference is absolutely neglegible.
$ python -m timeit "i = 5" "i *= i"
10000000 loops, best of 3: 0.0938 usec per loop
$ python -m timeit "is_there_anything_to_be_gained_from_short_variable_names = 5" "is_there_anything_to_be_gained_from_short_variable_names *= is_there_anything_to_be_gained_from_short_variable_names"
10000000 loops, best of 3: 0.0927 usec per loop
Ironically, when measured on this PC the long variable name was consequently measured ~0.001 usec faster per execution.
There's a problem with "like python", because not all interpreted languages are the same.
With a purely-interpreted language it would have more of an impact than with one like Python that has a pre-compile step. Strictly this isn't a language difference (you could have one Javascript engine that precompiles, and one that doesn't), but it does affect the answer to this question.
Stretching out "like python" to include every interpreted language, I'd say the answer is "yes, for some of them, at least some of the time". The next question is, "how much".
In 1997 through to early 1998 I was working on some rather complicated javascript code that made use of some of the new features of Netscape Navigator 4 and Internet Explorer 4. This was a humongous javascript file for the time - when the prevalence of dial-up meant that every kilobyte counted in terms of site speed.
For this reason, we used a minimiser script. The main thing this did, was to re-write variables to be shorter (lastHeight
becomes a
, userSel
becmomes b
and so on).
Not only did it reduce the download time, but it did also make one of the heavier functions appreciably faster. But only appreciable if you were someone who spent their whole working day looking at nothing else, which pretty much meant me and one other colleague.
So yes, if we put Javascript into the "like python" category as far as interpretation goes, then it can make a difference, under the following conditions:
And it still didn't make that much difference.
We can assume for that, that some other interpreted languages are also affected to a similarly minute degree.
Even in 1997 though, I wouldn't have bothered were it not that it coincidentally gave me another advantage, and I certainly wasn't working on the minimised version.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With