- From: David Bruant <bruant.d@gmail.com>
- Date: Tue, 04 Sep 2012 22:51:23 +0200
- To: Jonas Sicking <jonas@sicking.cc>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>, Alon Zakai <azakai@mozilla.com>
Alon Zakai wrote:
>>>> Technically it might
>>>> be possible to automatically rewrite such code to use asynchronous
>>>> coding patterns, but so far I don't think anyone has managed to do
>>>> that.
>>> Naively, I would say, that once we've paid the price to compile code
>>> from one language to another, you're not that far off from compiling
>>> to
>>> a given coding pattern. Especially compiling from LLVM bytecode.
>>> Regardless, has anyone tried at all? Has anyone tried to compile to
>>> JS+Promises or JS+task.js?
>> Consider even the simple and very common case of
>>
>> ..
>> while (!feof(f)) {
>> fread(buf, 100, 1, f);
>> ..process data in buf..
>> }
>> ..
>>
>> I don't have any good ideas for something asynchronous to compile this into that does not currently substantially harm performance. Compiling synchronous code into continuation passing style, generators, control flow emulation, or some other async style would greatly reduce performance.
I can imagine, it sounds hard indeed. Do you have numbers on how it
affects performance? Or an intuition on these numbers? I don't need to
be convinced that it affects performance significantly, but just to get
an idea.
I remember that at some point (your JSConf.eu talk last October), in
order to be able to compile through Emscripten, the source codebase (in
C/C++) had to be manually tweaked sometimes. Is it still the case? If
it's an acceptable thing to ask to authors, then would there be easy
ways for authors to make their IO blocking code more easily translated
to async JS code? I'm pessimistic, but it seems like an interesting
question to explore.
David
Received on Tuesday, 4 September 2012 20:51:54 UTC