Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The cost of parsing JSON

v8.dev

Post reply on HN
Print view View original

51–60 of 308 posts

Re: The cost of parsing JSON

#51

Post by shortercode »

no_gravity wrote: post #25

Because the JSON grammar is much simpler than JavaScript’s grammar, JSON can be parsed more efficiently than JavaScript. Hmm.. shouldn't that hold for most programming languages then? Let's try it for PHP: time php -r 'for ($i=0;$i So for 10 million repetitions, a small PHP structure is about 20x faster then parsing JSON. But to test the point of the article, one should use the sama data structure it uses ( https://r…

The possible syntax for Object literals is a lot more complicated than what JSON can contain. Hence the JSON parser is faster than the JS parser for the same object.

JS object literals allow such fun things as:

  {
    "foo": "bar",
    foo1: function () { return "bar" },
    foo2: () => "bar",
    foo3 () { return "bar" },
    get foo4 () { return "bar" },
    ["foo5"]: () => "bar"
  }

Re: The cost of parsing JSON

#53

Post by navaati »

omginternets wrote: post #36
epx wrote: post #33

This is the XOR AX,AX of the 21th century

What's XOR AX,AX of the 20th century?

This is assembly. This instruction is doing an boolean "Exclusive Or" of a register named "AX" (think of a register like a hardware variable) with itself into itself. This always leave the register containing 0, because 0 XOR 0 = 0 and 1 XOR 1 = 0.

And for some weird reason, doing that was faster than just doing MOV AX, 0 (which is literally "Move 0 into AX", so "AX = 0" in more familiar syntax).

Edit: Oh man, my fellow HN'ers, as I did, all jumped on the occasion to show off :)

Re: The cost of parsing JSON

#54

Post by jackcodes »

EGreg wrote: post #31
gqcwwjtg wrote: post #19

This makes total sense, it really just means that the time it takes to compile JSON.parse on a string literal is offset by how much simpler and faster parsing a JSON object is than a js one.

Why isn’t the Javascript compiler storing an intermediate form after parsing the code? Then surely it would be faster to just execute the bytecode?

It is, I believe. The article seems to be saying you can get to that intermediate form more quickly by parsing the object from a string than you can parsing it as a POJO.

Re: The cost of parsing JSON

#55

Post by pitaj »

no_gravity wrote: post #25

Because the JSON grammar is much simpler than JavaScript’s grammar, JSON can be parsed more efficiently than JavaScript. Hmm.. shouldn't that hold for most programming languages then? Let's try it for PHP: time php -r 'for ($i=0;$i So for 10 million repetitions, a small PHP structure is about 20x faster then parsing JSON. But to test the point of the article, one should use the sama data structure it uses ( https://r…

Please don't quote with code blocks. For mobile users:

> Because the JSON grammar is much simpler than JavaScript’s grammar, JSON can be parsed more efficiently than JavaScript.

Re: The cost of parsing JSON

#56

Post by omginternets »

navaati wrote: post #53
omginternets wrote: post #36

Earlier quoted context omitted.

What's XOR AX,AX of the 20th century?

This is assembly. This instruction is doing an boolean "Exclusive Or" of a register named "AX" (think of a register like a hardware variable) with itself into itself. This always leave the register containing 0, because 0 XOR 0 = 0 and 1 XOR 1 = 0. And for some weird reason, doing that was faster than just doing MOV AX, 0 (which is literally "Move 0 into AX", so "AX = 0" in more familiar syntax). Edit: Oh man, my fel…

Ah! Wow, that is surprising. Why was it so much faster?

Re: The cost of parsing JSON

#57

Post by basilgohar »

no_gravity wrote: post #25

Because the JSON grammar is much simpler than JavaScript’s grammar, JSON can be parsed more efficiently than JavaScript. Hmm.. shouldn't that hold for most programming languages then? Let's try it for PHP: time php -r 'for ($i=0;$i So for 10 million repetitions, a small PHP structure is about 20x faster then parsing JSON. But to test the point of the article, one should use the sama data structure it uses ( https://r…

A lot of the overhead in there is the call to the function json_decode. Function calls are much more expensive than operators in PHP. So this really isn't apples-to-apples.

The differences in data structures between the two languages may also play a significant role, what with PHP using complex z-val structs behind the scenes for almost all data types.

Re: The cost of parsing JSON

#58

Post by bryanlarsen »

no_gravity wrote: post #25

Because the JSON grammar is much simpler than JavaScript’s grammar, JSON can be parsed more efficiently than JavaScript. Hmm.. shouldn't that hold for most programming languages then? Let's try it for PHP: time php -r 'for ($i=0;$i So for 10 million repetitions, a small PHP structure is about 20x faster then parsing JSON. But to test the point of the article, one should use the sama data structure it uses ( https://r…

Better test:

    time for f in `seq 1000` ; do php -r '$data=[1,2,3];';  done
real 0m11.169s user 0m6.765s sys 0m4.477s

    time for f in `seq 1000` ; do php -r '$data=json_decode("[1,2,3]");';  done
real 0m9.997s user 0m6.093s sys 0m3.974s

Re: The cost of parsing JSON

#59

Post by 19ylram49 »

I mean, I get it, but I think performance is overrated in this particular case; unless it’s a significant and/or very noticeable difference, stick to object literals, please. I’d probably fire someone if I started to see `JSON.parse(…)` everywhere in a codebase just for “performance reasons” … remember, code readability and maintainability are just as important (if not more).

Re: The cost of parsing JSON

#60

Post by jedimastert »

omginternets wrote: post #36
epx wrote: post #33

This is the XOR AX,AX of the 21th century

What's XOR AX,AX of the 20th century?

The op "XOR" the the "xor" operation between two things and stores the result in the first operand. "XOR"ing a number with itself always results in 0, which is then stored in the operand itself.

This operation was almost always faster than moving a constant (like 0) into a register, because of all of the overhead of making the constant and reading and writing.

Post reply on HN