js optimization principles

This article shares with you the principles of js optimization. The content is quite good. Friends who are interested can take a look.

First of all, unlike other languages, the efficiency of JS largely depends on the efficiency of the JS engine. In addition to the pros and cons of engine implementation, the engine itself will also adopt some optimization strategies for some special code patterns. For example, the JS engines of FF, Opera and Safari have specially optimized the string concatenation operation (+). Obviously, to achieve maximum efficiency, you must understand the temperament of the engine and try to cater to the engine's taste. Therefore, for different engines, the optimizations made are most likely to run counter to each other.

And if you do cross-browser web programming, the biggest problem is IE6 (JScript 5.6)! Because without hotfix, the garbage collection bug of the JScript engine will cause its performance in real applications to not be on the same order of magnitude as other browsers. Therefore, optimizing in this situation is actually optimizing for JScript!

So the first principle is Only need to optimize for IE6 (unpatched JScript 5.6 or earlier)!

If your program has been optimized to acceptable performance under IE6, then basically there will be no problem with performance on other browsers.

Therefore, please note that many of the issues I talk about below may be completely different on other engines. For example, when string splicing is performed in a loop, it is usually considered that Array.join is required, but due to Engines such as SpiderMonkey have optimized the "+" operation on strings. As a result, using Array.join is not as efficient as using "+" directly! But if you consider IE6, this efficiency difference on other browsers is not worth mentioning at all.

JS optimization still has similarities with optimization in other languages. For example, don’t rush into optimization as soon as you start, as that is meaningless. The key to optimization is still to focus on the most critical place, which is the bottleneck. Generally speaking, bottlenecks always appear in large-scale loops. This is not to say that loops themselves have performance issues, but that loops can quickly amplify possible performance issues.

So the second principle is to take large-scale loops as the main optimization object.

The following optimization principles are only meaningful in large-scale loops. It is basically meaningless to do such optimization outside the loop body.

Currently, most JS engines are interpreted and executed. In the case of interpreted execution, the efficiency of function calls is low in all operations. In addition, excessively deep prototype inheritance chains or multi-level references will also reduce efficiency. In JScript, the overhead of level 10 references is roughly 1/2 of the overhead of an empty function call. The overhead of both is much greater than simple operations (such as four arithmetic operations).

So the third principle is to try to avoid too many reference levels and unnecessary multiple method calls.

It is important to note that in some cases, what appears to be property access is actually a method call. For example, all DOM properties are actually methods. When traversing a NodeList, the loop condition's access to nodes.length looks like attribute reading, but is actually equivalent to a function call. Moreover, in the implementation of IE DOM, childNodes.length must be re-counted through internal traversal each time. (My god, but this is true! Because I have measured that the access time of childNodes.length is proportional to the value of childNodes.length!) This is very expensive. Therefore, saving nodes.length to a js variable in advance can certainly improve the performance of traversal.

It’s also a function call, and the efficiency of user-defined functions is far lower than that of language built-in functions, because the latter is a wrapper for the engine’s native methods, and the engine is usually c, Written in c++, java. Furthermore, for the same function, the cost of built-in language constructs is usually more efficient than built-in function calls, because the former can be determined and optimized during the parse phase of the JS code.

So the fourth principle is to try to use the constructs and built-in functions of the language itself.

Here is an example of High-performance String.format method. The traditional implementation of String.format is to use String.replace(regex, func). When pattern contains n placeholders (including repeated ones), the custom function func is called n times. In this high-performance implementation, each format call only performs an Array.join and then a String.replace(regex, string) operation. Both are built-in methods of the engine without any custom function calls. Two built-in method calls and n number of custom method calls, this is the difference in performance.

are also built-in features, but there are still differences in performance. For example, the access performance of arguments in JScript is very poor, almost catching up with a function call. Therefore, if a simple function with variable parameters becomes a performance bottleneck, you can make some internal changes and do not access the arguments, but handle it through explicit judgment of the parameters.

For example:

##Java code

1. function sum() {

2. ## var r =

   0;

3. for (var i = 0; i

4. ##Q #return

   r;

5. ##}

6. This sum is usually called with a small number of parameters. We hope to improve its performance when there are fewer parameters. If changed to:

##Java code

function sum() {

switch

(arguments.length) {

1.          case

1
2. :

   return arguments[0];

3.                   case   2:   return arguments[0] +  arguments[1

   ];

4. ##case 3: return arguments[0] + arguments[1] + arguments[

   2
];

5. ##case 4: return arguments[0] + arguments[1] + arguments[2

   ] + arguments [
3
6. ];

   default: ## var r = 0;

7.              for (var i = 0; i

8. ##Q #         return

   r;   

9.                                                                                                     }

10. ##In fact, there will not be much improvement, but if it is changed to:

12. Java code

##function sum(a, b, c, d, e, f, g) {

## var r = a ? b ? c ? d ? e ? f ? a + b + c + d + e + f : a + b + c + d + e : a + b + c + d : a + b + c : a + b : a :
0

;

if (g === undefined)

return

r;
##for
2. (var i =

   6; i

## r += arguments[i];

3. }  

4. ##      

   return r;  

   }

will be much improved (at least 1x faster).

The last is the fifth principle, which is often the most important performance obstacle in real applications, that isMinimize unnecessary object creation.

There is a certain cost to creating the object itself, but this cost is actually not big. The most fundamental problem is that JScript’s extremely stupid garbage collection scheduling algorithm results in serious performance degradation as the number of objects increases (according to Microsoft people themselves, the complexity is O(n^2) ).

For example, our common string splicing problem, after my test verification, simply creating string objects multiple times is not actually the cause of poor performance at all. The worst part is the overhead of unnecessary garbage collection during object creation. The Array.join method does not create intermediate string objects, thus reducing the damn garbage collection overhead.

Therefore, if we can convert large-scale object creation into a single statement, its performance will be greatly improved! For example, by constructing the code and then eval - in fact, the PIES project is working on a specialized large-scale object generator based on this idea...

Okay. These are the five principles of JS optimization that I summarized.

##Reposted from ---------------hax's technology blog http://hax.iteye.com/blog/126859

Related recommendations:

js optimization works for IE6.0 (detailed arrangement)_javascript Skill

The above is the detailed content of js optimization principles. For more information, please follow other related articles on the PHP Chinese website!