Is there anything to be gained from short variable names?

Question

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.

Answer 1

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:

1. It was running on Pentium, Pentium Pro and 486s (Pentium II was out then, but we didn't have any). I got a new machine part-way through the project, which meant I went from 133MHz to 166MHz.
2. It was a rather large piece of nasty looping (most of the script had no appreciable difference).
3. It was running on a script-engine from 15years ago with none of the improvements in script-engine performance that have been made since.

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.

Answer 2

No. 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.

Answer 3

If you mean interpreted languages by the remark "languages like Python", then yes it will make a difference, as the parsing might take somewhat longer. The difference is unnoticeable I'd say.

I do completely agree with nightcracker though; don't do it. Make your code readable for a human being. Let the parser/compiler handle the readability for the machine.

Remember the rules about optimization:

1. Don't do it.
2. (Only for experts) don't do it yet.

Answer 4

You should use short variable names only for short-loop indexes and when the variable is short lived.

Use descriptive names otherwise, but don't overdo it and please don't use Hungarian notation.

Answer 5

Pretty much none. Admittedly it might slow down finding the variable name the first time when python is precompiling your script. However, the time expended as a result of the confusion that results from short variable names generally far exceeds the amount of time saved in the execution of the script.

Answer 6

Following from orlps answer, I considered that Python classes use a dictionary for lookups, so I wondered if there was any advantage in this regard.

import timeit

A = """
class A_CLASS_WITH_A_LONG_NAME:
    def a_function_with_a_long_name(self):
        return 1

A_CLASS_WITH_A_LONG_NAME().a_function_with_a_long_name()
"""

B = """
class A:
    def a(self):
        return 1

A().a()
"""

print(timeit.timeit(stmt = A, number = 1000000))
print(timeit.timeit(stmt = B, number = 1000000))

We get the figures:

• Long = 12.362802280999858
• Short = 11.445085418999952

Which are about 8% different.

Running inside a module (number = 100000000) instead of using timeit:

• Long = 24.87908697128296
• Short = 24.695187091827393

Which are about 1% different.

I would conclude there might be a difference with inlined code or the intricacies of the timeit profiler (timeit seems to be around 50x slower), but Cpython seems to do a good job of optimising away any differences. I cannot say if this would still hold true for a class with more members as the dict would have more buckets.