[whatwg] asynchronous JSON.parse

[Dan Beam]

On Thu, Mar 7, 2013 at 2:18 PM, David Rajchenbach-Teller <
dteller at mozilla.com> wrote:

> (Note: New on this list, please be gentle if I'm debating an
> inappropriate issue in an inappropriate place.)
>
> Actually, communicating large JSON objects between threads may cause
> performance issues. I do not have the means to measure reception speed
> simply (which would be used to implement asynchronous JSON.parse), but
> it is easy to measure main thread blocks caused by sending (which would
> be used to implement asynchronous JSON.stringify).
>

Isn't this precisely what Transferable objects are for?
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#transferable-objects

--
Dan Beam
dbeam at chromium.org


> I have put together a small test here - warning, this may kill your
> browser:
>    http://yoric.github.com/Bugzilla-832664/
>
> While there are considerable fluctuations, even inside one browser, on
> my system, I witness janks that last 300ms to 3s.
>
> Consequently, I am convinced that we need asynchronous variants of
> JSON.{parse, stringify}.
>
> Best regards,
>  David
>
> > Glenn Maynard wrote
> >
> > (It's hard to talk to somebody called "j", by the way.  :)
> >
> > On Thu, Mar 7, 2013 at 2:06 AM, <j at mailb.org> wrote:
> >
> >> right now JSON.parse blocks the mainloop, this gets more and more of an
> >> issue as JSON documents get bigger
> >
> >
> > Just load the data you want to parse inside a worker, and perform the
> > parsing there.  Computationally-expensive work is exactly something Web
> > Workers are meant for.
> >
> > and are also used as serialization
> >> format to communicate with web workers.
> >>
> >
> > There's no need to serialize to JSON before sending data to a worker;
> > there's nothing that JSON can represent that postMessage can't post
> > directly.  Just postMessage the object itself.
>
>
> --
> David Rajchenbach-Teller, PhD
>  Performance Team, Mozilla
>
>
>
>