Is a program more efficient if it uses shorter names in the source code?

Question

Or is a function with a shorter name more efficient than the same function with a longer name? Why or Why not?

Personally I guess it'll be more efficient but not efficient enough to make us care about it, just guess.

Answer 1

There is no performance difference, since those names don't matter at the machine level. A compiler will process those names away so it won't make a difference to your program at all.

Functions names might get turned into labels (which won't affect run-time performance), and variable names will probably get replaced by register reference or stack operations (both independent of the name you use). At this level, the OS is using (and jumping to) memory addresses, not names.

Answer 2

Longer symbol names might—ever so slightly—slow down compilation, but symbol length has no effect on execution time.

Some implementations of interpreters can be affected by symbol name length, but not most modern ones: they typically do a "compilation" step which removes symbol names from consideration, among other processing.

I used a 1972 HP desktop computer running interpreted BASIC. The user manual suggested use of short symbol names for speed—and to conserve memory.

Answer 3

To answer the letter of the question: a function with a long name will be exactly as efficient as one with a short name, unless it calls itself recursively (and in rare cases at that).

To answer the spirit of the question (guessing at it, of course): code using long identifiers in source code in the vast majority of modern languages running on modern computers, even those conventionally considered ‘interpreted’ will not be less efficient than code with short identifiers.

The general answer, with (okay, somewhat contrived) exceptions further down:

Black & White

Compiled Languages: the symbols are added to a symbol table during compilation. Symbol table size and complexity affect the runtime of the compiliation step but not the program's own runtime.

Interpreted Languages: the symbols are added to an intepretation-time dictionary of some sort, and the time needed to locate a symbol will be usually vary at a O(n) rate where n is the symbol length.

Shades of Grey

Compiled Languages: for one possible exception, take dynamic loading and introspection. For instance, in C on *nix, you can call the dlopen() function to open an shared object, then call the dlsym() function to locate data or subprograms in that object by name. This causes a search of the object's symbol table by name. If this is a major part of your program, then your program may end up having O(n) complexity with respect to the length of the objects. However, in practice, loading objects like this is only done to load modular units or plugins at initialisation time, and the lookups don't really happen much. The length of the symbols in your own program will still not affect runtime, of course.

Interpreted Languages: the vast majority of modern interpreted languages perform some serious optimisations and tokenisations, so in the end, referring to a long identifier or a short one may be 100% equivalent. Hashing, length limitations, etc all simplify things. It costs extra time (sometimes in the microseconds, on modern computers) to parse a longer identifier, and depending on the language this may be done every time the program is run, but up to once per program run. Unless you do a lot of evals, or a huge amount of introspection, you shouldn't see a problem. Even then, in the case of Python, introspection is dict-based, and dicts use hashing to locate keys, so runtime increases with the number of symbols, not their length.

But is it compiled or interpreted? The more you look, the fewer purely interpreted languages you'll find in use today. Python was mentioned in the comments, but Python compiles the source code into bytecode and internally refers to identifiers by tokens, not their full names. JavaScript engines do very similar things, depending on the particular implementation. Even (most of) the 8-bit BASICs of the Eighties performed tokenisation steps so that the program wasn't stored in textual form in memory (this saved both memory and CPU cycles, not in huge supply on 3 MHz, 64 KB computers), but in an intermediate form easily interpreted. Variable names would be put in a dictionary, and tokens (usually addresses) used to refer to them. Listing the program would effectively de-tokenise it for display.

Answer 4

This will depend on the platform you are targeting assuming you mean run time performance of release binaries.

For example on Symbian OS functions in DLL's are looked up via ordinal and so the name is never part of the binary. Thus the answer is no, it is not more efficient as it makes no difference since it never appears in the target image.

Answer 5

Efficient in terms of what? Memory used at run-time, memory used at compile-time, computation performed at run-time, computation performed at compile-time, size of executable, or something else?

Longer identifiers will require maginally more computation and memory at compile time. Also, a debug executable contains some symbols, so longer identifiers could affect debug executable size.

In terms of run-time computation and memory use, no, length of identifiers has no effect other than indirect effects from the previously mentioned differences.