Re: [whatwg] asynchronous JSON.parse

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

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

Received on Thursday, 7 March 2013 22:19:19 UTC