[whatwg] asynchronous JSON.parse

David Rajchenbach-Teller dteller at mozilla.com
Fri Mar 8 04:34:12 PST 2013

I fully agree that any asynchronous JSON [de]serialization should be
stream-based, not string-based.

Now, if the main heavy duty work is dealing with the large object, this
can certainly be kept on a worker thread. I suspect, however, that this
is not always feasible.

Consider, for instance, a browser implemented as a web application,
FirefoxOS-style. The data that needs to be collected to save its current
state is held in the DOM. For performance and consistency, it is not
practical to keep the DOM synchronized at all times with a worker
thread. Consequently, data needs to be collected on the main thread and
then sent to a worker thread.

Similarly, for a 3d game, until workers can perform some off-screen
WebGL, I suspect that a considerable amount of complex game data needs
to reside on the main thread, because sending the appropriate subsets
from a worker to the main thread on demand might not be reactive enough
for 60 fps. I have no experience with such complex games, though, so my
intuition could be wrong.

Best regards,

On 3/8/13 11:53 AM, David Bruant wrote:
> I don't think this is necessary as all the processing can be done a
> worker (starting in the worker even).
> But if an async solution were to happen, I think it should be all the
> way, that is changing the JSON.parse method so that it accepts not only
> a string, but a stream of data.
> Currently, one has to wait until the entire string before being able to
> parse it. That's a waste of time for big data which is your use case
> (especially if waiting for data to come from the network) and probably a
> misuse of memory. With a stream, temporary strings can be thrown away.
> David

David Rajchenbach-Teller, PhD
 Performance Team, Mozilla

More information about the whatwg mailing list