[whatwg] asynchronous JSON.parse

[Glenn Maynard]

On Thu, Mar 7, 2013 at 4: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.)
>

(To my understanding of this list, it's completely acceptable to discuss
this here.)

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

If you're dealing with lots of data, you should be loading or creating the
data in the worker in the first place, not creating it in the UI thread and
then shuffling it off to a worker.

For example, if you're reading a large file provided by the user, post the
File object (received eg. from <input>) to the worker, then do the heavy
lifting there in the first place.

Benchmarks are always good, but it'd be better to talk about a real-world
use case, since it gives us something concrete to talk about.  What's a
practical case where you would actually have to create the big object in
the UI thread?


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

> However, to use Transferable objects for purpose of implementing
> asynchronous parse/stringify, one needs conversions of JSON objects
> from/to Transferable objects. As it turns out, these conversions are
> just variants on JSON parse/stringify, so we have not simplified the issue.
>

(Not nitpicking, since I really wasn't sure what you meant at first, but I
think you mean a JavaScript object.  There's no such thing as a "JSON
object".)

-- 
Glenn Maynard