Re: [whatwg] Sending large structured data between threads without compromising responsiveness (was asynchronous JSON.parse)

Le 10/03/2013 21:17, David Rajchenbach-Teller a écrit :
> On 3/9/13 1:14 AM, Glenn Maynard wrote:
>> 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.)
> I concur with your points:
> - copying synchronously just to allow asynchronous transfer would be a
> performance killer;
> - somehow backgrounding a process while keeping processing on the
> performance-critical thread is no magic bullet.
>
> Both points seem to indicate that the API should not be of the
> fire-and-forget style but would rather require fine control by the
> developer, to ensure that it does not eat on performances.
>
> Hypothetically, this could be solved by an API with primitives to:
> 1. enqueue data to be sent;
> 2. allocate x milliseconds to processing/sending the data;
> 3. cancel sending some of the data;
> 4. cancel complete communication.
Could you expand on how you came to these 4 primitives, please?
It feels like a lot of reflection came from the current discussion to 
this conclusion, but I fail to understand it. Maybe one way to explain 
these 4 primitives would be to show how you want to solve the "save 
browser state" problem using them without freezing the browser.

In any case, ECMAScript 7 will very likely "steal" the event loop [1] 
from HTML5 and it seems that the primitive you're describing and the 
reflection that came to them would be worthwhile in the event loop 
reflection.
Maybe some part of this discussion should be moved to es-discuss or 
public-script-coord at some point.

> The idea being that all operations have (soft) time bound guarantees so
> can be interleaved by the user as part of a |requestAnimationFrame|
> loop. Also, data is never copied, so if this data changes before
> communication is complete, API clients need to handle invalidation on
> their own.
>
> Now, this sounds very much like something that can be implemented as a
> pure JS library.
I'm particularly puzzled about that especially on the "allocate x 
milliseconds to processing/sending the data", but I'm waiting for your 
explanations above to better understand what you mean.

David

[1] http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
[2] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop
>
>>      Seriously?
>>      FirefoxOS [1, 2] is a mobile operating system in which all applications
>>      are written in JavaScript, HTML, CSS. This includes the browser itself.
> [...]
>> That doesn't sound like a good idea to me at all, but in any case that's
>> a system platform, not the Web.
> [...]
>
> If you do not mind, I will not continue on this part of the
> conversation, as I believe that the core of the discussion has shifted
> anyway to the more general issue of sending large structured data
> between threads without compromising their responsiveness.
>
> Best regards,
>   David
>

Received on Sunday, 10 March 2013 20:34:08 UTC