Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Do variable names affect website performance? I know this will going to be very low number, but still can any one provide the reasons for not choosing a long variable name in aspect of performance?

share|improve this question
2  
Please clarify your question - where is this variable and what language is it written in? –  Luke Graham Jul 13 '11 at 14:13
12  
You should never, EVER choose short and illogical variable names if your reasoning is (questionable) performance. Source code is there for other people to read it, not for satisfying computers and their microscopic performance gains. –  Michael J.V. Jul 13 '11 at 14:22
    
i am using PHP.. –  Avinash Jul 13 '11 at 14:28
1  
...And you own xpertdeveloper.com? –  Jim G. Jul 13 '11 at 19:25
3  
Hi Avinash can you explain in your question your rationale for thinking that this might be the case? –  user8 Jul 13 '11 at 21:49

6 Answers 6

No, it will not. Generally speaking, when code is compiled, the variable names are replaced by the memory address they refer to. Computers don't know anything about variable names; they only want to know where values are stored.

Variables are symbols, nothing more. They replace hex values with names so that programmers have an easier time understanding what they're doing. So, there will be no performance boost by choosing shorter variable names.

That said, you may get miniscule (and I'm talking microscopic) improvements in compile times and the JIT first interpretation, but that is only because the parser takes a few CPU cycles less to read the variable name. This is a one-time cost, and is statistically insignificant when worrying about performance.

share|improve this answer
10  
While your answer is correct for application programming, the O.P is referring to Websites, and therefore there is a chance he is using an interpreted language. In such a case, the code would need to be read in from file, then interpreted. In this case, a longer variable name will take longer to load & parse. However the performance gain will be insignificant, and massively offset by the extra hassle to the programmer of reading and understanding the code. –  Gavin Coates Jul 13 '11 at 14:25
1  
@Gavin It is correct for interpreted languages as well - "JIT first interpretation". Most interpreted languages now compile as they execute rather than line by line execution, AFAIK. –  Michael K Jul 13 '11 at 14:39
1  
Michael - in order to compile, the file must first be read into memory. This process will take longer depending on the length of the file. Longer variable names = longer files. –  Gavin Coates Jul 13 '11 at 14:42

can any one provide the reasons for not choosing a long variable name in aspect of performance?

Michael covered the answer (i.e. No) but variable names do affect programmer performance. If you bring on a new developer or someone who's unfamiliar with the code, then having long and/or confusing variable names can be distracting and slow the comprehension process.

In general, you want to use short, descriptive variable names because they're easier to read. Imagine if you have to ignore your code for 10 years and then understand everything again. Would you rather read "getInput" or "getInputFromUserWhoInputsStringOrElseInformReaderOfError" ? (exaggeration of course :P)

There are times, however, when having a slightly longer name can be beneficial. For example, getBirthdayInput() would be much more descriptive than getInput(). You want to simplify to a point but oversimplification can also be problematic.

share|improve this answer
3  
for reading long names is better, if you find "getInputFromUserWhoInputsStringOrElseInformReaderOfError" you don't need to read documentation what's this function, if you find "getInput" you need. And after 10 years documentation will be wrong, or incomplete, or missing. getInputFromUserWhoInputsStringOrElseInformReaderOfError is certainly to long, but to understand about what it is long is better (and I don't care that women say that size does not matter). –  Dainius Jul 13 '11 at 14:31
    
I disagree in this case. I think just by reading code it would be pretty easy to understand what getInput() does, especially if it prints "invalid input" or something right afterward. There are definitely times when a longer name can be better though - I'll edit it in! –  BlackJack Jul 13 '11 at 14:34
    
ofc it depends from context, but in my experience longer name is better (but not so long as getInputFromUserWhoInputsStringOrElseInformReaderOfError). And context really important as file.read() is quicker than file.readAllFileAsByteArray(). But as I said usually IMHO longer name provides more information. –  Dainius Jul 13 '11 at 14:45
1  
If the documentation is wrong, incomplete, or missing, the codebase is doomed anyway. –  Christopher Mahan Jul 13 '11 at 16:01
    
This is answering a question that wasn't asked. –  user8 Jul 14 '11 at 20:29

While Michael is correct for application programming, your question is referring to web development with PHP, which is an interpreted language. In such a case, the code would need to be read in from file, then interpreted. In this case, a longer variable name will take longer to load & parse.

The performance hit with doing so however will be insignificant, and will probably be in the region of fractions of a millisecond for an entire script. You could always try it out with a sample script, and use a timing method such as that detailed at http://www.developerfusion.com/code/2058/determine-execution-time-in-php/ but this will probably not start timing until after the file has been read in. Additionally, the execution time between retries will vary far more than the difference between variable name lengths, so you will need to perform a significant number of retries and take the average of each before you can obtain a remotely meaningful average.

As BlackJack points out, longer names can be much more difficult to understand, and take a lot of extra effort to type out (and are much more prone to typo's). While there may be a tiny performance gain, this does not justify the extra hassle created for the programmer. As such, short, concise and easy to understand variable names are preferred.

So in short, don't worry about the variable length name, but instead concentrate on writing clean, meaningful code.

share|improve this answer

Unless you're using op-code cache (also known as "PHP accelerators"), then there is indeed an impact. But that impact is so low, that it can be neglected. If you do use op-code cache, then there is zero impact.

share|improve this answer
1  
and if you care about performance so much that you consider shortening variable names to gain a few cycles, not using op-code cache would be criminal... and switching to a compiled language like C would be recommended. –  SF. Jul 13 '11 at 23:45

Yes, it will, but not in the sense you are thinking about.

With bad variable names, developers will get easily confused in the source code. It will be hard to read and hard to understand.

In the end, the source code will be hard to maintain and it will be nearly impossible to make it evolve. This will lead inevitably to higher maintenance costs, higher development costs, more bugs, and poorer performances.

Variable name will have absolutely no influence at runtime, and totally negligible at compile time. But bad names will inevitably lead to bad performance because nobody understand the code and it ends up in a stack of hack one on top of another, making things worse each time.

Read these to know about good variable name: http://tottinge.blogsome.com/meaningfulnames

Note that if you feel the need of very long variable name, it means that your code is poorly architectured. A variable name is always expressed in a context: namespace, class name, filename, folder, function name, etc. Thus, if the name need to be long to be explicit, this means that the thing that you are trying to name DOESN'T BELONG HERE. In this case, think about putting this code in the appropriate place, or create that place if it doesn't exist yet.

share|improve this answer

Maybe:

Server code is typically compiled and variable name length will not affect it for the reasons mentioned. However, if the variable name is used to build markup various string operations. Since the HTTP response (containing markup/returned json/returned data) is larger, it will take slightly longer, although the difference will be negligible. If JavaScript is not minified, it will be a larger file, taking longer to travel to the client.

Other than minifying JavaScript files, any optimisation efforts for a web application/web site, will be better spent on other aspects.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.