How fast can a browser be?

React. js is famous for its efficient UI rendering. One of the most important reasons is that it maintains a virtual DOM, allowing users to operate React directly on the virtual DOM. js is famous for its efficient UI rendering. One of the most important reasons is that it maintains a virtual DOM, allowing users to perform operations directly on the virtual DOM, React. js uses the diff algorithm to obtain the minimum operation on the browser DOM, which avoids the performance loss caused by manual DOM modification. Wait. Why is the result faster when a layer is added in the middle? The core idea of React. js is that DOM operations are slow, so we need to minimize DOM operations in exchange for overall performance improvement. Slow DOM operations are obvious to all. Is other JavaScript scripts running faster?

Before V8 was born, the answer to this question was no. In its early years, Google's business model was built on the Web. When it wrote a very complex Web app like Gmail in a browser, it could not realize the unbearable performance of the browser, this is mainly because JavaScript Execution is too slow. In September 2008, Google decided to build its own JavaScript Engine to change this situation-V8. When the Chrome browser carrying V8 appeared on the market, its speed was far from all the browsers at that time. The unprecedented improvement in browser performance makes complex Web apps possible.

In the past seven years, the browser's performance has continued to increase with the CPU performance, but it has never achieved the breakthrough growth in 2008. What technologies does V8 use to greatly improve JavaScript performance?

V8 Optimization

To talk about how to make JavaScript faster, we should first talk about why it slows down. As we all know, JavaScript was developed by Brendan Eich over a week. Compared with Swift, which is currently booming, it is the result of four years of work by Apple's team, first, you probably shouldn't have high expectations for it. In fact, Brendan Eich didn't realize that he was developing such a mass language. To make the programming flexible, the programmer designs JavaScript as a weak language and can delete and modify the attributes of the object at runtime. The Inheritance and Polymorphism in a large group of C ++ do not exist in JavaScript. Who has done these jobs? Naturally, only the JavaScript engine is available. Because you do not know the variable type, it does a lot of Type derivation work at runtime. When Parser completes the work to create an abstract syntax tree (AST), the engine translates this AST into bytecode and submits it to the bytecode interpreter for execution. The most slow performance step is the stage in which the interpreter executes bytecode. Looking back at the time, do you know that the interpreter performance is low? Actually not. The reason for this design was that at that time, people generally thought that JavaScript was a language developed for designers (is front-end engineers feeling cool ?), It does not require too high performance. This meets the cost and needs.

V8 removes the slow engine speed. It directly generates a machine code that can be executed by the CPU from the AST. This instant compilation technique is called JIT (Just in time ). If you are curious, a natural idea is, what should you do?

Let's take an example:

function Foo(x, y) {    this.x = x;    this.y = y;}var foo = new Foo(7, 8);var bar = new Foo(8, 7);foo.z = 9;

Attribute reading

The first is the data structure. How are you going to index the attributes of an object? We are too familiar with the data structure of key: value in JSON, but can we index it with key in memory? Can I determine the position of value in the memory? Of course, you only need to maintain a table for each object, and the value corresponding to each key is stored in the memory, right?

The trap here is that you need to maintain such a table for every object. Why? Let's take a look at how C is implemented.

struct Foo {    int x, y;};struct Foo foo, bar;foo.x = 7;foo.y = 8;bar.x = 8;bar.y = 7;// Cant' set foo.z

Think about the textbooks in college. The addresses of foo. x and foo. y can be calculated directly. This is because the types of members x and y are determined. In JavaScript, foo. x = "Hello" can be used completely, and C language cannot do this.

V8 does not want to maintain such a table for each object. It also wants JavaScript to have the feature that C/C ++ can read attributes directly by offset. So its solution is to make dynamic types static. V8 implements a feature called the Hidden Class, which assigns a Hidden Class to each object. For the foo object, it generates a class similar to this:

class Foo {    int x, y;}

When a bar object is created, its x and y attributes are exactly of the int type, so it shares the hidden class with the foo object. After determining the type, the read attribute only adds an offset to the memory. When foo creates the z attribute, V8 finds that the original class is unavailable and creates a new hidden class for foo. The same is true for modifying attribute types.

Inline caching

As we can see from the above, when accessing an object's attributes, V8 must first determine the current hidden class of the object. But every time you do this, the overhead is very high. Another common solution that is easy to think of on a computer is caching. When you access a given object attribute for the first time, V8 assumes that all other objects in the same part of the Code also use the hidden class of this object, therefore, the system will tell other objects to directly use the class information. When accessing other objects, if the verification is correct, you only need one command to obtain the required attributes. If the verification fails, V8 will automatically cancel the optimization. The above section is expressed in code:

foo.x

# ebx = the foo objectcmp [ebx,
 
  ],
  
   jne 
   
    mov eax,[ebx, 
    
     ]
    
   
  
 

This greatly increases the speed of the V8 engine.

As Intel announces the delay of the Tick-Tock model, the CPU processing speed will no longer grow as before. Can the browser continue to grow faster? Is V8 optimized the end of browser performance?

The problem with JavaScript is that it is wrong to assume that front-end engineers are low-level programmers (if not, you should not read it here). It makes programmers comfortable to write and makes computer execution suffer. When the modern browser engine has been optimized to this point, we cannot help wondering: Why must it be JavaScript? Can front-end engineers make a step by doing more, so that the engine can optimize performance more efficiently? JavaScript is actually a browser script standard for historical reasons, but it cannot be an excuse for us to stop making progress.

When Web Assembly was officially announced, I was sure that not only a well-known small programmer had the idea that the top minds in the world had started to act. Driven by a large number of demands, the browser is moving towards a high-performance direction. 2015 may be another turning point on this road.