W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2013

Re: [whatwg] asynchronous JSON.parse

From: David Bruant <bruant.d@gmail.com>
Date: Fri, 08 Mar 2013 11:53:03 +0100
Message-ID: <5139C30F.5030606@gmail.com>
To: David Rajchenbach-Teller <dteller@mozilla.com>
Cc: whatwg@whatwg.org
Le 07/03/2013 23:18, David Rajchenbach-Teller a écrit :
> (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}.
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.

Received on Friday, 8 March 2013 10:53:33 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:56 UTC