Non-Blocking Asynchronous JSON.parse Using the Fetch API(azimi.me)

34 pointsby mohsen1vor 11 Jahren13 comments

Non-Blocking Asynchronous JSON.parse Using the Fetch API

http://azimi.me/2015/07/30/non-blocking-async-json-parse.html

13 comments

zamalekvor 11 Jahren

> For each message to be sent to or received from a worker we need to convert it to a string.

Strange, according to MDN data sent to web workers needs only be deep clone-able[1]. Is this non-standard Gecko behavior?

> aMessage: This may be any value or JavaScript object handled by the structured clone algorithm, which includes cyclical references.

[1]: https://developer.mozilla.org/en-US/docs/Web/API/Worker/post...

jwmerrillvor 11 Jahren

Using the structured clone algorithm for worker postMessage calls is standard:

https://html.spec.whatwg.org/multipage/workers.html#communic...

msoadvor 11 Jahren

It converts it to a string anyway.

zamalekvor 11 Jahren

Gecko, at the very least, maintains cycles in the object graph. This is something that a naïve JSON round-trip can't do.

fsdffsvor 11 Jahren

If you add a wrapper, maybe use a simple heuristic to switch between JSON.parse and fetch. Even something as simple as checking the length of the string may cut it: lower than X? use JSON.parse . Higher? Use fetch.

nalleroothvor 11 Jahren

Sounds reasonable. This might, however, differ between different browsers too.

jwmerrillvor 11 Jahren

This doesn't actually succeed (yet?) at avoiding blocking the UI thread while parsing large chunks of JSON. The async API means that browsers could parse JSON from fetch responses on a different thread, but it doesn't mean that they do.

Here's a jsbin experiment that shows that the main thread is blocked while parsing JSON using the author's technique (tested in Chrome 44 and Firefox 41):

http://jsbin.com/yutahe/8/edit?js,output

davejvor 11 Jahren

My results on Chrome 43 running on an i7 Macbook Pro. JSON generated from: http://beta.json-generator.com/NJG1eN49

~34KB json string (1st run):

    sync: total time (blocking): 0.412ms
    async: blocking time: 1.822ms
    async: total time: 3.943ms
    ➜ str.length
    34527

~34KB json string (10th run):

    sync: total time (blocking): 0.569ms
    async: blocking time: 0.438ms
    async: total time: 2.336ms

~112KB json string (1st run):

    sync: total time (blocking): 1.217ms
    async: blocking time: 1.036ms
    async: total time: 4.818ms
    ➜ str.length
    114745

~112KB json string (10th run):

    sync: total time (blocking): 1.658ms
    async: blocking time: 0.683ms
    async: total time: 4.444ms

Could do with some proper benchmarking by someone who knows more about benchmarking this stuff for real-world usage (i.e.. not me). By the way the 2nd - 10th run results were pretty similar, the amount of time that async function was blocking gradually decreased as it was run more often (I ran the ~34KB tests first).

m1elvor 11 Jahren

Maybe it would be better to create a streaming message passing API. e.g. send an object in smaller parts instead of passing JSON and then sending it to the worker and fetch it in parts.

efxzshvor 11 Jahren

Hmm, ok but why not

function asyncParse(string) { return new Promise(function(res, rej) { resolve(JSON.parse(string)); }); }

- or -

let asyncParse = async (string) => JSON.parse(string);

alt_vor 11 Jahren

Promises still run in the main thread and will block other javascript. The purpose of this hack is to move the parsing out of the main thread.

efxzshvor 11 Jahren

Ok, get it. Thx

jchomalivor 11 Jahren

I totally agree with this