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

71–80 of 308 posts

Re: The cost of parsing JSON

#71

Post by lacker »

19ylram49 wrote: post #59

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).

Well, they are suggesting it for literals that are 10 kB or larger. That means they aren't really talking about code that's in your normal codebase - it's quite rare to have a literal that large. It is more likely this is relevant for backend tools that autogenerate JavaScript code to be sent to a client.

Re: The cost of parsing JSON

#72

Post by nostrebored »

Klathmon wrote: post #62
Tade0 wrote: post #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…

I find this really interesting, because at some point the absolute performance benefits of `JSON.parse` is overshadowed by the fact that it blocks the main thread. I worked on an app a while ago which would have to parse 50mb+ JSON objects on mobile devices. In some cases (especially on mid-range and low-end devices) it would hang the main thread for a couple seconds! So I ended up using a library called oboe.js [1]…

Why not just use promises?

side note: legit question, I don't do web/app dev

Re: The cost of parsing JSON

#73

Post by ijpoijpoihpiuoh »

pier25 wrote: post #24
ijpoijpoihpiuoh wrote: post #2

Title correction: it's faster to parse and initialize using JSON than to parse and compile the code required to initialize Objects directly. If the code is already compiled, it's much faster to initialize in code. At least that's my understanding of the linked article.

Is there a way to provide v8 with compiled code instead of unparsed JS?

I don't know about doing this directly with v8, but when used in the browser, the code will be cached after being compiled a certain number of times.

Re: The cost of parsing JSON

#74

Post by murderfs »

jedimastert wrote: post #66
omginternets wrote: post #56

Earlier quoted context omitted.

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

There's a bunch of overhead associated with reading a constant from the program and moving that to the register. Math operations, on the other hand, are very simple to do because it's baked right into the CPU, only requiring one instruction and a few cycles

No, the reason is that `xor ax, ax` has a shorter encoding, because it only takes 3 bits to encode a register on 32-bit x86, and far more bits are required for a useful immediate move. It would be ridiculous to have a short encoding for `mov rN, #imm` where the immediate has to be in the range 0-7.

Re: The cost of parsing JSON

#75

Post by Kuinox »

nostrebored wrote: post #72
Klathmon wrote: post #62

Earlier quoted context omitted.

I find this really interesting, because at some point the absolute performance benefits of `JSON.parse` is overshadowed by the fact that it blocks the main thread. I worked on an app a while ago which would have to parse 50mb+ JSON objects on mobile devices. In some cases (especially on mid-range and low-end devices) it would hang the main thread for a couple seconds! So I ended up using a library called oboe.js [1]…

Why not just use promises? side note: legit question, I don't do web/app dev

Because JS is single threaded. If a task is too big you need to split it or the UI can't be updated until the task is done.

Re: The cost of parsing JSON

#76

Post by zeven7 »

jacobr wrote: post #67
SamBam wrote: post #61

Earlier quoted context omitted.

It seems that you could define a subset of JS Objects that are exactly those you could define with JSON (no functions, no recursion), and the browser could always read these more efficiently. With modern tooling, these could probably even be automatically be discovered at compile time, and all your `const a = {b: "c"}` objects could be changed into `const a = SimpleObject({b: "c"})`. Without that, you could probably…

There is no way of knowing someone won’t do a.foo = window.alert later though, unless it’s a frozen object

That's also true of an object parsed with JSON.parse

Re: The cost of parsing JSON

#77

Post by doomslice »

nostrebored wrote: post #72
Klathmon wrote: post #62

Earlier quoted context omitted.

I find this really interesting, because at some point the absolute performance benefits of `JSON.parse` is overshadowed by the fact that it blocks the main thread. I worked on an app a while ago which would have to parse 50mb+ JSON objects on mobile devices. In some cases (especially on mid-range and low-end devices) it would hang the main thread for a couple seconds! So I ended up using a library called oboe.js [1]…

Why not just use promises? side note: legit question, I don't do web/app dev

Promises still run on "the main thread" so a CPU intensive task in a promise is still going to block things. You could use a promise if you delegated your CPU task to another process or some C code that did actual threading.

I believe you'd use Workers (WebWorkers?) https://developer.mozilla.org/en-US/docs/Web/API/Workers to actually do it off the main thread entirely inside JS.

Re: The cost of parsing JSON

#78

Post by no_gravity »

bryanlarsen wrote: post #58
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

Awesome. So it does hold true for PHP as well.

Re: The cost of parsing JSON

#79

Post by earthboundkid »

nostrebored wrote: post #72
Klathmon wrote: post #62

Earlier quoted context omitted.

I find this really interesting, because at some point the absolute performance benefits of `JSON.parse` is overshadowed by the fact that it blocks the main thread. I worked on an app a while ago which would have to parse 50mb+ JSON objects on mobile devices. In some cases (especially on mid-range and low-end devices) it would hang the main thread for a couple seconds! So I ended up using a library called oboe.js [1]…

Why not just use promises? side note: legit question, I don't do web/app dev

Promises still run in the main thread.

You could try to use a web worker, but then you run into the problem that they don't have shared memory, so you need to pass data back some other way.

Re: The cost of parsing JSON

#80

Post by RussianCow »

nostrebored wrote: post #72
Klathmon wrote: post #62

Earlier quoted context omitted.

I find this really interesting, because at some point the absolute performance benefits of `JSON.parse` is overshadowed by the fact that it blocks the main thread. I worked on an app a while ago which would have to parse 50mb+ JSON objects on mobile devices. In some cases (especially on mid-range and low-end devices) it would hang the main thread for a couple seconds! So I ended up using a library called oboe.js [1]…

Why not just use promises? side note: legit question, I don't do web/app dev

Promises are a way to deal with async code. Parsing JSON is synchronous and CPU-bound, so promises offer no benefit. And since web pages are single-threaded[0], there isn't really any way you can parse JSON in the background and wait on the result.

[0]: There is now the Web Workers API which does allow you to run code in the background. I've never used it, but I have heard that it has a pretty high overhead since you have to communicate with it through message passing, so it's possible you wouldn't actually gain anything by using it to parse a large JSON object.

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

Post reply on HN