On Sun, Mar 26, 2017 at 8:16 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:
> 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. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
