Does Variable Name Length Affect JavaScript Code Speed? | by Nicholas Obert | Sep, 2022

Program size matters. Kind of

Photo by Deon Black on Unsplash

If you’ve been programming for a while, chances are that you’ve come across the following question: does the length of the variable names affect the code runtime performance in any way?

At first, that may seem like a silly question. After all, who in the world would choose ambiguous three-letter variable names instead of more descriptive and readable identifiers, except for old-school C developers? However, this is a legitimate question that opens up the possibility of learning some interesting concepts you may find useful in your software developer journey.

When a programming language source code gets compiled into machine code, the concept of variable start to lose its meaning. All that’s left of objects, classes, functions, and all these high-level concepts are just memory addresses, jump instructions, and simple operations. In particular, variables are translated into memory addresses and offsets.

JavaScript, however, isn’t generally compiled directly into machine code but rather interpreted by a JavaScript engine such as Google’s V8. The execution pipeline of JavaScript code is rather complex: the engine has to create the appropriate execution contexts and scope chain, parse the source code and compile it into an executable bytecode for a virtual machine to run. freeCodeCamp does a great job explaining this process in their article “JavaScript Execution Context — How JS Works Behind The Scenes” by Victor Ikechukwu.

This article will explore how the length of variable names can affect a program’s performance.

First, let’s do a performance benchmark to see whether there is any noticeable difference. For this test, I wrote a simple JavaScript script that compares the execution speed of two functions: short_name and long_name. The former uses short one-letter variable names while the latter uses 16-kilobyte-long names. If there’s any speed difference, this large gap should make it noticeable.

For the benchmark, I used the benchmark library for its high-resolution timers and statistically significant results. Note that here I replaced the 16-KB names with shorter ones so that you don’t have to download uselessly large files.

And here are the benchmark results:

Short name x 523 ops/sec ±0.95% (89 runs sampled)
Long name x 521 ops/sec ±1.00% (88 runs sampled)
The fastest option is Short name,Long name

As you can see, there doesn’t seem to be any difference in speed between the two functions. However, don’t stop reading yet: the interesting part is coming now. Let’s dive deeper into how JavaScript handles variables.

As I mentioned before, JavaScript is compiled into bytecode before execution. To compare the two functions’ bytecode, I split them into two separate files. Also, the long variable names are one megabyte each to emphasize any difference further.

To generate the V8 bytecode, I used bytenode, a minimalist bytecode compiler for Node.js written in JavaScript. To compile the JavaScript source code, type in these commands:

npx bytenode -c short_name.js
npx bytenode -c long_name.js

This generates two bytecode files: long_name.jsc and short_name.jsc. Now, let’s print the file sizes with du to see if there’s any difference. After all, the variable names should still be there.

du short_name.jsc long_name.jsc -h --apparent-size840 short_name.jsc
978K long_name.jsc

As you can see, there’s a huge difference in size: the latter is around 1,000 times larger. We should find the variables if we inspect the bytecode with a hex editor (I used the VSCode built-in one).

1*s7SEqvkjaDtI5QI9ad y2w
1*mURjRi9YCxIU6 ujKL0ZgQ

And indeed, the variable names are still there. However, symbol names (variables, functions…) are stored only once in the bytecode and then referenced using offsets and addresses instead of their ASCII names. As a result, long_name.jsc is about a megabyte large: the length of the long l variable. Also, the i used inside the for loop has vanished. Honestly, I don’t know enough about JavaScript to tell why there’s no i in the bytecode. I guess that’s an optimization.

Now that you know that there’s a great difference between the two generated bytecode files, you may wonder how their runtime performance is the same. In the previous benchmark, the timer was started only after the whole program had been loaded into memory and read by the JavaScript engine.

If we call the function at the end of short_name.js and long_name.js and perform the speed test using the time utility, we should see a difference:

time node long_name.jsreal 0m0,132s
user 0m0,111s
sys 0m0,021s
time node short_name.jsreal 0m0,058s
user 0m0,048s
sys 0m0,011s

And indeed, there’s a difference. time measures how long the program takes to exit from its launch. This also includes the time it takes to read the file from the disk and for the JavaScript engine to pass through every byte to execute the code. Of course, the more bytes, the longer it takes to handle them.

As for the previous benchmark, as I mentioned, there’s no performance difference because once loaded, the symbols are accessed via offsets and addresses like array elements, so there’s no reference to their names.

To wrap up, we’ve seen how the program size affects your code’s runtime performance. However, the examples in this article are extreme cases you probably won’t ever encounter during your career. Also, once the program is loaded, there won’t be any performance difference because of the way symbols are handled in the bytecode.

Moreover, you should never trade source code readability for smaller file sizes. An appropriately descriptive variable name is always better than a three-consonant word like old-school C developers used to do back when they used teletypewriters and paper (and some still do).

If you’re particularly keen on keeping the file size as small as possible, for example, for faster transfer over the internet, you can always take advantage of minification, the process of removing all unnecessary characters from the source code without changing its functionality, and thus lowering bandwidth usage and decreasing a website’s loading time.

So, does variable name length affect JavaScript execution speed? Yes, at least in theory. In practice, it doesn’t make any noticeable difference.

I hope you enjoyed this article. If you have anything to add, please share your thoughts in a comment. Thanks for reading!

If you’re interested in enhancing your JavaScript code bases, take a look at this story below:

News Credit

%d bloggers like this: