Processing time is affected by the size of variable names?

Asked

Viewed 209 times

8

I was analyzing some frameworks developed by large companies and noticed a certain uniqueness, its variables and functions usually have small names.

Variable or function name size interferes with processing time?


By the logic I would say yes, because read 4 bytes instead of 20 it would make searching for the variable or function faster.

  • Related or duplicated: http://answall.com/questions/31485/o-size-de-uma-fun%C3%A7%C3%A3o-affects-a-performance-e-consumo-de-mem%C3%B3ria It’s not exactly the same thing but I think it’s the same purpose. Summarizing the link: in compiled languages the names disappear, in fully interpreted languages there is so much inefficiency that one more will not make a difference (or, already have to parse even that the size is worth being smaller? ). When making statements it would be good to cite examples to give more context. You may have a specific reason. Is it dup? If not, I’ll answer.

  • @bigown I think the difference between there and here is that in the other question we analyzed the size of the function. Here we analyze the size of the names of the variables.

  • I was curious to know which frameworks have function names and variables so small that it is remarkable as a common feature among them. What are?

2 answers

8


In compiled languages, your code is translated into machine language. The variables you call "foo", "bar", "_auxTempObj" etc... Saw sequences of zeros and ones generated at compiler convenience.

Today’s processors have "input ports" for their records that pass 64 bits at a time (this is the meaning of the 64-bit architecture ;) ), so anything with less than that is completed with zeros.

Thus, the relationship between name size and performance is practically irrelevant. Variables shall be named in such a way that they are legible by persons, not by machines.

Now for the interpreted languages.

The simple act of reading a word is an algorithm of complexity O(n). Who is nerd studied enough to understand this already understood that the conclusion for interpreted languages is the same conclusion 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 if that weren’t true... an interpreter can ride a hash table with variable names and working 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 said several times that you should not worry about the impact on performance. But the fact that you have thought that this can affect the performance of the program, this curiosity, is the mark of the good developer. Even if any reason for concern is undone by theory and practice, the concepts you need to know to understand this question will help you program better.

  • The answer itself is perfect, I just don’t quite understand this 64-bit thing. I think that’s not quite how it works. Did you not confuse it with cache line who is 64 bytes? Unless a specific algorithm is built, which rarely happens, treating multiple characters at once or perhaps using SSE instructions, each character processed individually. There is advantage of not having to load one by one because of the cache, but as far as I know, only this. I lost something?

  • @bigown I just imagine that a compiler transforms every variable in the code into a symbol during translation. Regardless of the symbol format, generally eight bytes should be sufficient to hold all possible symbols representing something in the program (unless you have more than 2 64 variables...)

  • Now I understand what you’re saying, I thought you were putting that Parsing occurred in groups of 64 bits (8 bytes) at a time.

5

Compiled languages

In compiled languages the name of variables is important only to the compiler. When the program finishes being compiled, these names no longer exist, they are only memory addresses that will be accessed at runtime. So the name does not make the slightest difference in the processing of the application. The computer does not care about variable names. This is an abstraction for humans to understand the code better. So use the names for this, to make your code as comprehensible as possible.

Is it possible that someone thinks that to do the Parsing Consume more time because the names of variables are larger. Technically this is true but this is so tiny, so little closer to the whole that needs to be done and a reduction of names would bring so many problems that it is not worth even thinking about it. Comments cause even more time loss during the build process and no one dares to say that they should not use any comments to make the build less than 0.1% faster.

Note that some languages are compiled to some intermediate form (a bytecode or a AST). In these cases the process usually works analogous to the compilation for native code.

Interpreted languages

When the language is fully interpreted, which is rare nowadays, then the compilation process interpolates with the execution of the code itself, then it will have a small loss, but again, the loss is so tiny that it will make no real difference. It will be difficult to measure the difference, probably other uncontrollable 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 a few extra characters makes no difference even if the processing of the application itself is very small. The extra time if we consider only the interpretation will already be very derisory.

And note that even interpreters usually only waste time with the initial interpretation, the subsequent accesses will probably be done optimally through symbols.

Names of small variables in frameworks

The frameworks that I know do not usually worry about the size of the variables. Sometimes the unconcern is so great that they arrive to have names like this: InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState. His only problem is that even humans can’t understand this.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.