On 1/31/14, 3:25 PM, Paolo Amadini wrote:
I have just filed bugs to make sure our DOM Promise implementation is
on par with Promise.jsm in these areas:
- Make state, value and reason inspectable in the debugger (bug 966471)
- Report all unhandled rejections to the Console on GC (bug 966452)
- Make handlers inspectable in the debugger (bug 966472)
- Dump "coding" exceptions thrown by handlers (bug 966462)
I think the first two are the most important. When these are ready,
migration of Promise.jsm consumers to DOM Promises will be pretty easy,
since both are based on the original Promises/A+ specification, and
when bug 941757 about "new Promise()" is fixed the Promise.jsm API
will match the one of DOM Promises.
Nice work!
I do have one lingering question.
After re-reading the "Intent to replace Promise.jsm and promise.js with
DOM Promises" thread, most of the discussion centered around feature
parity. I don't believe anyone has asked the question: what's the impact
of this on performance?
The transition from vanilla callbacks to promises initially scared me on
the performance front because promises involve multiple function calls
instead of a single function call. What swayed me towards accepting
promises was a) generator magic (via Task.jsm) leading to much more
comprehensible and maintainable code and b) knowledge that JS would grow
to accept promises natively (presumably meaning that they'd eventually
get optimized by the engine).
If we switch Promise.jsm to DOM Promises, AFAICT we're moving from
promises being 100% JS to involving a bridge to C++/DOM. Doesn't this
add overhead and thus regress performance? Will it impact JIT
behavior/perf anywhere?
Gregory
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
