Re: [whatwg] asynchronous JSON.parse

I'd like to hear about the use cases a bit more. 

Generally, structured data gets bulky because it contains more items, not because items get bigger.

In which case, isn't part of the solution to paginate your data, and parse those pages separately?

Even if an async API for JSON existed, wouldn't the perf bottleneck then simply fall on whatever processing needs to be done afterwards?

Wouldn't some form of event-based API be more indicated? E.g.:

var parser = JSON.parser();
parser.parse(src);
parser.onparse = function(e) {
  doSomething(e.data);
};

And wouldn't this be highly dependent on how the data is structured, and thus very much app-specific?

--tobie 


On Thursday, March 7, 2013 at 11:18 PM, David Rajchenbach-Teller 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).
> 
> 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 (http://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:35:07 UTC