Writing in the front

Original address:

www.bram.us/2019/11/25/…

The original text contains the YouTube video, which has a ladder and can be viewed directly by clicking on the link if you speak English.

For readers who look too long

Because JSON syntax is simpler than Javascript syntax, parsing JSON is more efficient than parsing Javascript. When a Web app needs to load for the first time, we can improve the first-screen load performance by parsing a very complex, large, JSON-compliant object literal configuration object (such as configuring redux’s Store).

whyJSON.parsefaster

useASTsaidJSON.parse(...)More simple

In AST, represents json.parse (…) Even simpler, it contains only one token of type CallExpression and one of type StringLiteral.

The code for equivalent object literals is much more complex, depending on the complexity of the object represented by the JSON string. Each key value is a token of type StringLiteral and each token of type NumericLiteral. But in JS, this value can actually be of any type.

If the object contains nested structures, there are more tokens and value types involved, which means that the JS interpreter has to spend extra time parsing them to make sure the code executes correctly.

explainJSON.parse(...)More simple

Parse (‘{this code, when the interpreter tries to interpret it, only two things happen:

  • It is a legal oneJSONString if it takes{The first word of
  • It is an illegal oneJSONstring

For {, things get a lot more complicated. Let’s start with a piece of code:

const x = 42
const y = ({ x }
Copy the code

With this code, the interpreter reads this byte without knowing in advance what might happen next. Could y really be an object literal here, or could it be anything else? If the interpreter does not execute subsequent code, it cannot draw any conclusions.

If the second line of code looks like this:

const y = ({ x })
Copy the code

Y represents an object, and x here refers to the x variable in the first line of code, which is 42.

But if the second line of code looks like this:

const y = ({ x } = { x: 21 })
Copy the code

The y here is going to be 21, and the first x is going to be used for structure assignment, and it’s going to point to the x in the later object that has the value 21.

That’s not all. What if the code looks like this?

const y = ({ x }) => x
Copy the code

Here y performs an anonymous arrow function, and x represents a structure assignment parameter.

These examples show that for a JS engine, interpreting a piece of code involves analyzing a lot of things depending on the context in which it is placed, which can take a lot of time, whereas json.parse is much simpler.

benchmark

You can see at least 1.5x performance improvements across a variety of JS engines.

Use advice

While using Json.parse can improve performance, it is not recommended to apply it manually for two reasons:

  • useJSON.parseLess readable than using Object literals
  • JSONString parameters do not enjoy the editor’s highlighting

It is recommended that this step be incorporated into the compilation and packaging of the code, for example using the babel-plugin-object-to-json-parse plug-in. (Note: This plugin is an experimental version and is not recommended for production until stable)

reference

  • V8. Dev/blog/cost – o…

Pay attention to the public account full stack 101, only talk about technology, not life