JavaScript replaces global variables with local variables 1th/2 page _javascript tips

Why did you do that? What's the basis? How much damage can be done to performance without doing so? This article explores the answers to these questions and fundamentally understands what factors are involved in the reading and writing properties of variables.
Copyright notice
This article translates fromNicholas C. ZakasOn February 10, 2009 on the personal website published on theJavaScript Variable Performance》。 The original version is the only official edition, and this is a simplified Chinese translation (Simplified Chinese translation) authorized by the original author (Nicholas C. Zakas). The translator (informed) has made a lot of efforts in the accuracy of translation, and promised that the content of the translated text is completely loyal to the original, but may still contain omissions and irregularities, and you are welcome to correct me. The content is informal and represents only the translator's personal point of view.

The following is the translation of the original text :
One of the most common suggestions for how to improve JavaScript performance is to use local variables (global variables) as much as possible instead of variables. In my nine years of web development work, this advice has always been in my ear and has never been questioned, and the basis of this proposal comes from the way JavaScript handles scopes (scoping) and identifier parsing (identifier resolution).

First, we need to be clear that the function in JavaScript as a specific object, the process of creating a function, in fact, is the process of creating an object. Each function object has an internal property called [[Scope]], which contains the scope information when the function is created. In fact, the [[Scope]] property corresponds to a list of objects (Variable Objects) that can be accessed from within a function. For example, if we build a global function A, then the [[scope]] internal property of a has only one global object, and if we create a new function B in a, then the [[scope]] property of B contains two objects. Function A's activation object is preceded by a global object, which is in the back row.

When a function is executed, a executable object (Execution object) is automatically created, and a scope chain (scope Chain) is bound at the same time. The scope chain is established using the following two steps for identifier resolution.

1. The objects in the internal properties of the function object [[Scope]] are first copied to the scope chain in order.
2. Second, when the function executes, a new activation object is created that contains the definition of this, parameters (arguments), local variables (including named arguments), and this activation Object objects are placed at the front of the scope chain.

In the process of executing JavaScript code, when an identifier is encountered, the search is performed in the scope chain of the execution context (Execution contexts) based on the name of the identifier. Starts from the first object in the scope chain (the function's activation object) and, if not found, searches for the next object in the scope chain, and so forth, until the definition of the identifier is found. If the last object in the scope is not found after searching, that is, the global object, an error is thrown that prompts the user that the variable is undefined (undefined). This is the process of performing the function execution model and identifier parsing (Identifier resolution) described in the ECMA-262 standard, and it turns out that most JavaScript engines do. It should be noted that ECMA-262 does not enforce the requirement for this structure, but only describes this part of the function.

After understanding the process of identifier parsing (Identifier resolution), we can see why local variables are faster to parse than other scoped variables, mainly because the search process is significantly shortened. But how much faster will it be? To answer this question, I simulated a series of tests to test the performance of variables in different scoping depths.

The first test is to write one of the simplest values to a variable (the literal value 1 is used here), and the results are shown in the following illustration, which is interesting:

It is not difficult to see from the results that when the identifier parsing process requires a deep search, it will be accompanied by performance loss, and the degree of performance loss will increase as the identifier depth increases. Unsurprisingly, Internet Explorer is the worst performer (but, to be fair, IE 8 has some improvement). It is noteworthy that there are some exceptions, Google Chrome and the latest webkit in the time to access variables to maintain a stable, not with the scope of the increase in depth. Of course, this is due to the next generation of JavaScript engines, V8, and squirrelfish they use. These engines are optimized for code execution, and it is clear that these optimizations make accessing variables faster than ever. Opera is also very good, much faster than IE, Firefox and the current version of Safari, but slower than V8 and squirrelfish browsers. The Firefox 3.1 Beta 2 performance is a bit surprising and efficient for local variables, but as the number of scoping layers increases, efficiency is compromised. Note that I use the default settings here, which means Firefox does not have trace enabled.

Current 1/2 page 12 Next read the full text