I was analyzing some frameworks developed by large companies and noticed a particular uniqueness, their variables and functions usually have small names.
By logic I would say yes, because reading 4 bytes instead of 20 would make the search for the variable or function faster.
In compiled languages, your code is translated into machine language. The variables that you call "foo", "bar" , "auxTempObj" etc ... have seen sequences of zeros and ones generated in the compiler convenience.
Today's processors have "gateways" to their records that pass 64 bits at a time (this is the meaning of 64-bit architecture;)), so anything with less than that is completed with zeros.
In this way, the relationship between name size and performance is almost irrelevant. Variables must be named in such a way that they can be read by people, not by machines.
Now let's interpret the languages.
The simple act of reading a word is an algorithm of O (n) complexity. Whoever is nerd studied enough to understand this has already understood that the conclusion for interpreted languages is the same as for compiled languages.
In human language, what this means is that reading variable names is "cheap" computationally. In practical terms, variable names will not be the bottleneck when interpreting your code. The simple act of determining the scopes of each part of the code is orders of magnitude more expensive than reading the names. So once again, name the variables thinking about who will keep your code.
Even though this was not true ... An interpreter can set up a hash table with the names variables and work with hashes. Depending on the algorithm, this would be equivalent to having all variable names of the same size. Again, it's not worth worrying about.
Just to conclude: I have spoken several times that you should not worry about the impact on performance. But the fact that you thought it might affect the performance of the program, that curiosity, is the mark of the good developer. Although any reason for concern is broken by theory and practice, the concepts you need to understand to understand this issue will help you to better plan.
In compiled languages the names of variables are important only to the compiler. When the program finishes compiling, these names no longer exist, they are just memory addresses that will be accessed at runtime. So the name does not make any difference in the processing of the application. The computer does not want to know about variable names. This is an abstraction for humans to better understand the code. So use the names for this to make your code as comprehensible as possible.
It is possible that somebody thinks that to do the parsing consume more time because the variable names are larger. Technically this is true but this is so small, so little close to the whole that needs to be done and a reduction of names would bring so many problems that it is not worth thinking about. Comments cause even more time-wasting during the compilation process and no one dares to say that they should not use any comments to make the compilation less than 0.1% faster.
Note that some languages are compiled into some intermediate form (a bytecode or a < in> AST ). In these cases the process usually works in a way analogous to the compilation for native code.
When the language is fully interpreted, which is rare nowadays, then the compilation process interpolates with the execution of the code itself, so it will have a small loss, but again, the loss is so small that it will not make any real difference. It will be difficult to even measure the difference, probably other non-controllable factors will make more difference than this, you will always be within the margin of error. Analyzing otherwise, an interpreted code is so inefficient that having to parse some extra characters does not make a difference even if the application itself is very small. The additional time if we consider only the interpretation will already be very derisory.
And note that even interpreters often only waste time on the initial interpretation, subsequent hits will probably be optimized through symbols .
The frameworks that I know do not usually worry about the size of the variables. Sometimes the unconcern is so great that they get to have names like this: InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState . His only problem is that even humans can not understand it.
