Switching to async/await from Task.jsm/yield

Till Schneidereit till at tillschneidereit.net
Mon Mar 27 03:32:20 UTC 2017

On Sun, Mar 26, 2017 at 8:16 PM, Ehsan Akhgari <ehsan.akhgari at gmail.com>

> On 2017-03-17 7:41 PM, Kris Maglione wrote:
> > On Fri, Mar 17, 2017 at 07:30:46PM -0400, Ehsan Akhgari wrote:
> >> Have we measured the performance of our async/await implementation?  I
> >> think we should definitely do some extensive testing of the performance
> >> of any new ES primitives before deciding to switch to using them in the
> >> front-end code en masse.  Of course, if the performance result aren't
> >> good, that doesn't mean we shouldn't use them in the front-end code, it
> >> means we need to make the performance better.  :-)  But we need to be
> >> able to make the trade-off cautiously.
> >
> > Yes. There was performance testing for the self-hosted version (which
> > was basically the same as the Promise.jsm implementation) before it was
> > converted to C++, and after:
> >
> > https://bugzil.la/1314055
> >
> > In short, it's better, but not hugely.
> That's quite nice if you ask me.  :-)  I have see code surrounding this
> stuff show up in profiles a lot, although I admit I haven't had a way to
> measure the overhead of this part directly.  And often times the way
> that this matters is in a "death by a thousand cuts" scenario, i.e.,
> when in some edge case something is taking super long, this overhead
> makes things much worse, so I'm really happy to see this happening!

Additionally, the async/await implementation will get faster eventually.
There are quite a few ways to optimize it which we haven't yet implemented.
They're not exactly trivial, so this isn't necessarily a short-term thing,
but they'll definitely happen. So if we change as much code as possible to
using async/await instead of Promise.jsm, we'll get the benefits of this
automatically in many areas of the browser.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20170326/26b46b58/attachment.html>

More information about the firefox-dev mailing list