On 2/3/14 11:48 AM, Gregory Szorc wrote:
> what's the impact of this on performance?
It's hard to say without an example of the sort of code whose
performance we're worried about.
> because promises involve multiple function calls instead of a single
> function call.
Note that in general not all function calls are created equal....
What's generally slow-ish is calls from C++ into JS, whether those
happen in the DOM or in the JS engine. And single-callee calls from JS
into C++ are a bit slower than single-callee calls from JS into JS,
since the latter can get inlined.
Now whether you're in a single-callee situation, whether your code is
getting inlined, and whether your code is even getting JIT-compiled
(e.g. your typical JSM is not in many cases) is all a bit unclear for
the cases we're talking about here. Again, concrete code examples may
make this clear. Or may not. :(
What swayed me towards accepting
promises was a) generator magic (via Task.jsm) leading to much more
comprehensible and maintainable code
I should note that if you're using generators, you're clearly not _that_
worried about performance, in today's world. At least for the code
inside the generator function, since that's not JIT-compiled at all so
far; it runs in the interpreter.
and b) knowledge that JS would grow
to accept promises natively
That will still happen, probably. Of course they'll be C++ objects,
just like the DOM promises (and just like array objects, etc).
(presumably meaning that they'd eventually
get optimized by the engine).
That's possible, but which parts are you thinking about specifically?
Are you worried about the performance of promise creation (which
involves a call from C++ to JS, passing in the resolve/reject
functions), or resolve()/reject() calls on a promise, of then() calls on
a promise, or of the cost of promises invoking their callbacks (another
C++ to JS call)?
If we switch Promise.jsm to DOM Promises, AFAICT we're moving from
promises being 100% JS to involving a bridge to C++/DOM.
The bridge _to_ C++/DOM is pretty fast (think overhead on the order of
20 instructions per call). The bridge back into JS is a different
story; that's probably 20x slower.
But again, it really depends on what the 100% JS code did.
Doesn't this add overhead and thus regress performance?
Hard to say without measuring.
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
