5 ms·

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 thre

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] to incrementally parse the massive JSON blobs putting liberal `setTimeout`'s between each step to avoid hanging the main thread for more than about 200ms at a time. This meant that it would often take 5x longer to fully parse the JSON blob than just using `JSON.parse`, but it was a much nicer UX as the UI would never hang or freeze during that process (at least perceptively), and the user wasn't waiting on that parsing to happen to use the app, there was still more user-input I needed from them at that time. So even though it would often take 15+ seconds to parse now, the user was often spending 30+ seconds inputting more information, and now the UI would be fluid the whole time.

nostrebored 7y ago
Why not just use promises? side note: legit question, I don't do web/app dev
- Kuinox 7y ago
  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.
- doomslice 7y ago
  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 https://developer.mozilla.org/en-US/docs/Web/API/Workers to actually do it off the main thread entirely inside JS.
- earthboundkid 7y ago
  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.
  - earthboundkid 7y ago
    IndexedDB runs on web workers, so that might be a good way to push the work off the main thread but still share the result.
- RussianCow 7y ago
  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_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
- Klathmon 7y ago
  Because JSON.parse blocks the thread it's in, and JS is single threaded [1]. So even if you put it behind a promise, when that promise actually runs, it will block the thread. In essence, using promises (or callbacks or timeouts or anything else like that) allows you to delay the thread-blocking, but once the code hits `JSON.parse`, no other javascript will run until it completes. And since no other javascript will run, the UI is entirely unresponsive during that time as well. [1] Technically there are web-workers, and I looked into them to try and solve this problem. Unfortunately any complex-objects that get sent to or from a worker need to be serialized (no pass-by-reference is allowed except for a very small subset of "C style" arrays called TypedArrays). So while you could technically send the string to a worker and have the worker call `JSON.parse` on it to get an object, when you go to pass that object back the javascript engine will need to do an "implicit" `JSON.stringify` in the worker, then a `JSON.parse` in the main thread. Making it entirely useless for my usecase. But continuing with that same thought process, I very nearly went for an architecture that used a web-worker, did the `JSON.parse` in the worker, then exposed methods that could be called from the main thread to get small amounts of data out of the worker as needed. Something like `worker.getProperty('foo.bar.baz')` which would only take the parsing hit for very small subsets of the data at a time. But ultimately the oboe.js solution was simpler and faster at runtime.
  - nostrebored 7y ago
    Thank you for the excellent explanation! I think of js entirely from a node.js perspective where I conceptualize it as an async task. Is this also wrong?
    - Klathmon 7y ago
      Node suffers from the same issues, but it's generally not as noticable in most cases. A similar situation in node would cause the server to not be able to respond to any other requests during the `JSON.parse` execution. But in the Node world, you have more options for how to get around those problems (like load balancing requests among several node processes). But both server-side and client-side JS use the same system, the event loop. It's basically a message-queue of events that get stacked up, and the JS engine will one at a time grab the oldest event in that queue and process it to completion. Anything "async" will just throw a new event into that queue of events to be processed. The secret sauce is that any IO is done "outside" the JS execution, so other events can be processed while the IO is waiting to complete. Take a look at this link, or search up the JS event-loop if you want to get a better explanation. It's deceptively simple. https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop https://developer.mozilla.org/en-US/docs/Web/JavaScript/Even...
- Rapzid 7y ago
  JSON.parse is not interruptible. All the answers about promises and single threading are interesting but that's the crux of the issue.
sbr464 7y ago
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 < 2 ? n : fib(n - 1) + fib(n - 2)) onmessage = msg => { console.log('fibonacci worker onmessage', msg) postMessage({ num: msg.data, result: fib(msg.data) }) } [1] https://github.com/bharathnayak03/react-webworker-hook https://github.com/bharathnayak03/react-webworker-hook
- Klathmon 7y ago
  Web workers won't work in this case because they need to serialize all data going into and out of them (with the exception of TypedArrays). So passing a string to a worker and having it JSON.parse it works great. But when you go to pass that object back to the main thread, it implicitly does a JSON.stringify and a JSON.parse back on the main thread (technically it's called a "Structured Copy", but it's mostly the same thing), putting you in the exact same situation.
  - sbr464 7y ago
    Good to know, thanks for clarifying.
    - Klathmon 7y ago
      And thanks to you for helping show me that I wasn't the only one to try that! This whole thread has been really nice to read, because I beat my head against a wall for a long time before I finally found a solution, and I'm glad to read that I wasn't the only one to think this was a lot more deceptively hard than I thought at first thought (or second, or third...)
  - kllrnohj 7y ago
    > it implicitly does a JSON.stringify and a JSON.parse back on the main thread (technically it's called a "Structured Copy", but it's mostly the same thing) Except funnily enough JSON.stringify + JSON.parse is usually recommendation as it's either comparable or faster than the structured copy the engine itself does :/ Web workers are depressingly bad...
penagwin 7y ago
I'm asking purely out of curiosity - what was the content of such a large JSON object?
- Klathmon 7y ago
  It was a carton scanning app, so basically a massive array of objects (carton data) which were needed so the app could function and route cartons and validate deliveries entirely offline. Due to some unfortunate limitations from our clients and some edge cases, we couldn't filter down the data on the server ahead of time. So we ended up having to keep that massive amount of data on the device, and at the end of the day 95% of it would be unused, but we wouldn't know which 95% until the device was already offline. It was a system where the goalposts moved many times during the development. If I were to do it again, I wouldn't use JSON, but after having the goals change a few times and then having the original server-side components get co opted to work on other projects, it was hard to justify the time that would be spent switching to a different, more appropriate wire format.
  - zaroth 7y ago
    I kept reading that as cartoons and I was just so confused for a second...
tracker1 7y ago
Would probably break that up similar to how you did in that case as well. Though may use multiple server request (chunks) and/or use a websocket for the data feed. What was the memory overhead for the application?
- Klathmon 7y ago
  I don't remember details about memory stuff, it was a few years ago now, but I was pleasantly surprised to see that it wasn't nearly as bad as I first assumed it would be. And I did originally plan on using something like a websocket, but turns out with some minor changes on the server side we could start streaming data while it was still being gathered, and oboe.js is actually able to start parsing data even while it's still downloading from a normal XHR request, and is designed to be as efficient as possible (so it throws away string data as soon as it's not needed any more). So there weren't really any additional benefits to be had from using websockets and breaking it up into multiple distinct requests would probably have been slower! (I just realized I forgot to add a link to oboe.js! But I highly recommend it. It seems it's just gotten better since the last time i've used it) [1] http://oboejs.com http://oboejs.com
clinta 7y ago
Is that relevant when comparing parsing json with parsing literal objects? I don't know much about JavaScript engines but I'd expect that parsing literal objects in code is also blocks the main thread.
nojvek 7y ago
If you really need to work with large data files 1mb+. Json is a terrible format. You should look into flat buffers. It’s like having indexed json where there is no parsing cost. You can have millions of rows and nested objects and it will only read the bytes it needs. It is length prefix encoded format so it’s pretty safe to work in a streaming manner too.
- smileypete 7y ago
  Good article on how Facebook used them for their mobile app: https://code.fb.com/android/improving-facebook-s-performance-on-android-with-flatbuffers/ https://code.fb.com/android/improving-facebook-s-performance...

nostrebored 7y ago

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

Kuinox 7y ago
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.
doomslice 7y ago
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 https://developer.mozilla.org/en-US/docs/Web/API/Workers to actually do it off the main thread entirely inside JS.
earthboundkid 7y ago
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.
- earthboundkid 7y ago
  IndexedDB runs on web workers, so that might be a good way to push the work off the main thread but still share the result.
RussianCow 7y ago
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_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
Klathmon 7y ago
Because JSON.parse blocks the thread it's in, and JS is single threaded [1]. So even if you put it behind a promise, when that promise actually runs, it will block the thread. In essence, using promises (or callbacks or timeouts or anything else like that) allows you to delay the thread-blocking, but once the code hits `JSON.parse`, no other javascript will run until it completes. And since no other javascript will run, the UI is entirely unresponsive during that time as well. [1] Technically there are web-workers, and I looked into them to try and solve this problem. Unfortunately any complex-objects that get sent to or from a worker need to be serialized (no pass-by-reference is allowed except for a very small subset of "C style" arrays called TypedArrays). So while you could technically send the string to a worker and have the worker call `JSON.parse` on it to get an object, when you go to pass that object back the javascript engine will need to do an "implicit" `JSON.stringify` in the worker, then a `JSON.parse` in the main thread. Making it entirely useless for my usecase. But continuing with that same thought process, I very nearly went for an architecture that used a web-worker, did the `JSON.parse` in the worker, then exposed methods that could be called from the main thread to get small amounts of data out of the worker as needed. Something like `worker.getProperty('foo.bar.baz')` which would only take the parsing hit for very small subsets of the data at a time. But ultimately the oboe.js solution was simpler and faster at runtime.
- nostrebored 7y ago
  Thank you for the excellent explanation! I think of js entirely from a node.js perspective where I conceptualize it as an async task. Is this also wrong?
  - Klathmon 7y ago
    Node suffers from the same issues, but it's generally not as noticable in most cases. A similar situation in node would cause the server to not be able to respond to any other requests during the `JSON.parse` execution. But in the Node world, you have more options for how to get around those problems (like load balancing requests among several node processes). But both server-side and client-side JS use the same system, the event loop. It's basically a message-queue of events that get stacked up, and the JS engine will one at a time grab the oldest event in that queue and process it to completion. Anything "async" will just throw a new event into that queue of events to be processed. The secret sauce is that any IO is done "outside" the JS execution, so other events can be processed while the IO is waiting to complete. Take a look at this link, or search up the JS event-loop if you want to get a better explanation. It's deceptively simple. https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop https://developer.mozilla.org/en-US/docs/Web/JavaScript/Even...
Rapzid 7y ago
JSON.parse is not interruptible. All the answers about promises and single threading are interesting but that's the crux of the issue.

sbr464 7y ago

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 < 2 ? n : fib(n - 1) + fib(n - 2)) onmessage = msg => { console.log('fibonacci worker onmessage', msg) postMessage({ num: msg.data, result: fib(msg.data) }) } [1] https://github.com/bharathnayak03/react-webworker-hook https://github.com/bharathnayak03/react-webworker-hook

Klathmon 7y ago
Web workers won't work in this case because they need to serialize all data going into and out of them (with the exception of TypedArrays). So passing a string to a worker and having it JSON.parse it works great. But when you go to pass that object back to the main thread, it implicitly does a JSON.stringify and a JSON.parse back on the main thread (technically it's called a "Structured Copy", but it's mostly the same thing), putting you in the exact same situation.
- sbr464 7y ago
  Good to know, thanks for clarifying.
  - Klathmon 7y ago
    And thanks to you for helping show me that I wasn't the only one to try that! This whole thread has been really nice to read, because I beat my head against a wall for a long time before I finally found a solution, and I'm glad to read that I wasn't the only one to think this was a lot more deceptively hard than I thought at first thought (or second, or third...)
- kllrnohj 7y ago
  > it implicitly does a JSON.stringify and a JSON.parse back on the main thread (technically it's called a "Structured Copy", but it's mostly the same thing) Except funnily enough JSON.stringify + JSON.parse is usually recommendation as it's either comparable or faster than the structured copy the engine itself does :/ Web workers are depressingly bad...

penagwin 7y ago

I'm asking purely out of curiosity - what was the content of such a large JSON object?

Klathmon 7y ago
It was a carton scanning app, so basically a massive array of objects (carton data) which were needed so the app could function and route cartons and validate deliveries entirely offline. Due to some unfortunate limitations from our clients and some edge cases, we couldn't filter down the data on the server ahead of time. So we ended up having to keep that massive amount of data on the device, and at the end of the day 95% of it would be unused, but we wouldn't know which 95% until the device was already offline. It was a system where the goalposts moved many times during the development. If I were to do it again, I wouldn't use JSON, but after having the goals change a few times and then having the original server-side components get co opted to work on other projects, it was hard to justify the time that would be spent switching to a different, more appropriate wire format.
- zaroth 7y ago
  I kept reading that as cartoons and I was just so confused for a second...

tracker1 7y ago

Would probably break that up similar to how you did in that case as well. Though may use multiple server request (chunks) and/or use a websocket for the data feed. What was the memory overhead for the application?

Klathmon 7y ago
I don't remember details about memory stuff, it was a few years ago now, but I was pleasantly surprised to see that it wasn't nearly as bad as I first assumed it would be. And I did originally plan on using something like a websocket, but turns out with some minor changes on the server side we could start streaming data while it was still being gathered, and oboe.js is actually able to start parsing data even while it's still downloading from a normal XHR request, and is designed to be as efficient as possible (so it throws away string data as soon as it's not needed any more). So there weren't really any additional benefits to be had from using websockets and breaking it up into multiple distinct requests would probably have been slower! (I just realized I forgot to add a link to oboe.js! But I highly recommend it. It seems it's just gotten better since the last time i've used it) [1] http://oboejs.com http://oboejs.com

clinta 7y ago

Is that relevant when comparing parsing json with parsing literal objects? I don't know much about JavaScript engines but I'd expect that parsing literal objects in code is also blocks the main thread.

nojvek 7y ago

If you really need to work with large data files 1mb+. Json is a terrible format. You should look into flat buffers. It’s like having indexed json where there is no parsing cost. You can have millions of rows and nested objects and it will only read the bytes it needs. It is length prefix encoded format so it’s pretty safe to work in a streaming manner too.

smileypete 7y ago
Good article on how Facebook used them for their mobile app: https://code.fb.com/android/improving-facebook-s-performance-on-android-with-flatbuffers/ https://code.fb.com/android/improving-facebook-s-performance...