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.