Live data from Hacker News

The cost of parsing JSON

v8.dev

41–50 of 308 posts

Re: The cost of parsing JSON

#41

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…

PHP doesn't run inside Chrome's JS engine as far as I know... probably apples and oranges here.

Re: The cost of parsing JSON

#42

So I guess we should "transpile" static objects into strings that we call with JSON.parse? Not sure if I should end this comment with a /s or not.

Sometimes you can have massive static objects. Like a list of emojis and their codepoints.[1] It could be useful in cases like that. You'd have to experiment, though.

[1] https://raw.githubusercontent.com/joypixels/emoji-toolkit/ma...

Re: The cost of parsing JSON

#43

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…

Your example compares parsing 1 time with parsing 10000000 times.

PHP does not re-parse code during execution.

Re: The cost of parsing JSON

#44

So I guess we should "transpile" static objects into strings that we call with JSON.parse? Not sure if I should end this comment with a /s or not.

The key part here is

> As long as the JSON string is only evaluated once the JSON.parse approach is much faster.

So doing this would only work on top-level declarations, because the javascript runtime will cache the parsed JSON structure for subsequent executions (eg. creating an object in a loop).

Re: The cost of parsing JSON

#47
post #33

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

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

xor'ing a value with itself produces 0, so XOR AX,AX is equivalent to "AX = 0". It's a common trick in assembly code because it's faster (and/or maybe more compact, can't remember) than the more obvious MOV AX,$0.

Re: The cost of parsing JSON

#48
I think this fragment catches the spirit of this piece:

A good rule of thumb is to apply this technique for objects of 10 kB or larger — but as always with performance advice, measure the actual impact before making any changes.

Although it may still not be worth it. At work I have this hand-rolled utility for mocking the backend using a .har file(which is a JSON). I use it to reproduce bugs found by the testers, who are kind enough to supply me both with such a file and a screencast.

On a MacBook Pro a 2.6MB .har file takes about 140ms to parse and process.

Re: The cost of parsing JSON

#50
post #38

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…

But you're not parsing the array 10000000 times in the first example. Use `eval`.

Not sure if eval is the right choice as the article compares parsing json to using a native js structure as well.

The correct comparison would be to try it on the 7MB json data the article is based on.

Post reply on HN