Re: [whatwg] asynchronous JSON.parse

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

> I have put together a small test here - warning, this may kill your
> browser:
>    http://yoric.github.com/Bugzilla-832664/
>

By the way, I'd recommend keeping sample benchmarks as minimal and concise
as possible.  It's always tempting to make things configurable and dynamic
and output lots of stats, but everyone interested in the results of your
benchmark needs to read the code, to verify it's correct.


On Fri, Mar 8, 2013 at 9:12 AM, David Rajchenbach-Teller <
dteller@mozilla.com> wrote:

> Ideally, yes. The question is whether this is actually feasible.
>
Also, once we have a worker thread that needs to react fast enough to
> provide sufficient data to the ui thread for animating at 60fps, this
> worker thread ends up being nearly as critical as the ui thread, in
> terms of jank.
>

I don't think making a call asynchronous is really going to help much, at
least for serialization.  You'd have to make a copy of the data
synchronously, before returning to the caller, in order to guarantee that
changes made after the call returns won't affect the result.  This would
probably be more expensive than the JSON serialization itself, since it
means allocating lots of objects instead of just appending to a string.

If it's possible to make that copy quickly, then that should be done for
postMessage itself, to make postMessage return quickly, instead of doing it
for a bunch of individual computationally-expensive APIs.

(Also, remember that "returns quickly and does work asynchronously" doesn't
mean the work goes away; the CPU time still has to be spent.  Serializing
the complete state of a large system while it's running and trying to
maintain 60 FPS doesn't sound like a good approach in the first place.)

Seriously?
> FirefoxOS [1, 2] is a mobile operating system in which all applications
> are written in JavaScript, HTML, CSS. This includes the browser itself.
> Given the number of companies involved in the venture, all over the
> world, I believe that this qualifies as "real use case".
>

That doesn't sound like a good idea to me at all, but in any case that's a
system platform, not the Web.  APIs aren't typically added to the web to
support non-Web tasks.  For example, if there's something people want to do
in an iOS app using UIWebView, which doesn't come up on web pages, that
doesn't typically drive web APIs.  Platforms can add their own APIs for
their platform-specific needs.

-- 
Glenn Maynard

Received on Saturday, 9 March 2013 00:14:47 UTC