BackburnerJS / backburner.js

A rewrite of the Ember.js run loop as a generic microlibrary
MIT License
392 stars 80 forks source link

Use microtask queue to flush autoruns... #306

Closed rwjblue closed 6 years ago

rwjblue commented 6 years ago

This PR is just a small stepping stone towards leveraging microtasks a bit more (with the goal of removing Ember's autorun assertion)...

rwjblue commented 6 years ago

With the last commit (using MutationObserver when possible), the new test (confirming autorun flush happens before a bb.later(fn, 0)) passes on all supported browsers.

stefanpenner commented 6 years ago

seems good, this may need to be major bump, so it can ride the canary train in ember. Some caveats may exist re: popup blockers and window.open being run in autoruns.

Table of funky behavior is here: https://github.com/BackburnerJS/backburner.js/issues/181 (we may deem it irrelevant)

rwjblue commented 6 years ago

seems good, this may need to be major bump, so it can ride the canary train in ember

Ya, we definitely want it to go through a full canary -> beta -> release cycle so we can ensure this has no negative ramifications.

FWIW, I have been working on the next step (advancing from queue to queue during an autorun via microtask queue flushes) in https://github.com/rwjblue/backburner.js/pull/1 if you are interested in the followup progress...

stefanpenner commented 6 years ago

FWIW, I have been working on the next step (advancing from queue to queue during an autorun via microtask queue flushes) in rwjblue#1 if you are interested in the followup progress...

Sounds like a good approach.

My long-term thought was to essentially make auto-run default, and if Ember.run is wrapping, abide by it. We can do a VC call if you want someone to chat about it.

rwjblue commented 6 years ago

Yep, that’s exactly the direction I am pushing on. Will pester you tomorrow to chat through it some more 😆...

rwjblue commented 6 years ago

I just ran a series of benchmarks comparing various versions of backburner (v0.3.1 used by Ember 2.13, v1.3.4 used by Ember 2.18, v2.1.0 used by Ember 3.0.0-beta.5, master at e65437d, and this PR's changes) against a complex real world app.

As you can see below, compared to e65437d we have a very high confidence that this has a positive impact on performance (estimated difference is -153ms):

microtask-progression-vs-2-1-0

Full results

rwjblue commented 6 years ago

@stefanpenner / @krisselden - I'd like to land this (given the strong evidence shown above) so that we can update Ember and continue fleshing out our plans RE: native promises and whatnot. Any objections?