The cost of parsing JSON

Post by tzs » Wed, Sep 18, 2019, 4:56 PM UTC

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

Post by keanebean86 » Wed, Sep 18, 2019, 4:57 PM UTC

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.

Post by tomtomtom777 » Wed, Sep 18, 2019, 4:59 PM UTC

murderfs wrote: post #74

jedimastert wrote: post #66

Earlier quoted context omitted.

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.

Post by sbr464 » Wed, Sep 18, 2019, 5:02 PM UTC

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]…

  const fib = n => (n  {
    console.log('fibonacci worker onmessage', msg)
    postMessage({ num: msg.data, result: fib(msg.data) })
  }

Post by Klathmon » Wed, Sep 18, 2019, 5:10 PM UTC

sbr464 wrote: post #97

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]…

You can also pretty easily use a web worker now, they work well. Here's [1] an example with React hooks. Example fibonacci worker code that doesn't block the UI, even at larger calculations const fib = n => (n { console.log('fibonacci worker onmessage', msg) postMessage({ num: msg.data, result: fib(msg.data) }) } [1] https://github.com/bharathnayak03/react-webworker-hook