These setTimeout() changes have been pushed to inbound: https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=7c6116ac71e954805dccf3146d6fffcf28bbc0cf
Please need-info me if you encounter any problems. I'll check back later. Thanks! Ben On Tue, May 30, 2017 at 10:34 PM, Ben Kelly <[email protected]> wrote: > FYI, this did not land last week. However, I do intend to land it > tomorrow pending a few last reviews. > > Also, I ended up making changes that keeps our setTimeout() firing > behavior closer to our old behavior. We can still fire slightly early as > dictacted by our nsITimer implementation. Our precision should be > approximately the same as behavior. > > The main benefit of this landing will be reduced allocation and locking > overhead when setTimeout()/setInterval() is used. > > On Thu, May 25, 2017 at 11:00 AM, Ben Kelly <[email protected]> wrote: > >> Hi all, >> >> I want to give everyone a heads-up that I'm hoping to push some >> setTimeout() changes to inbound in the next day or two: >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1363829 >> >> The main result people should be aware of is that setTimeout() will be >> more accurate and precise after this lands [1]: >> >> 1. We will no longer be able to fire setTimeout() handlers early. >> 2. Assuming an idle main thread setTimeout() handlers will be less >> delayed. >> 3. setTimeout(f, 0) may be a simple runnable dispatch now and can fire a >> bit faster than before. >> >> As you can imagine, changing setTimeout() timings has interesting effects >> on our test results. I've been working hard to find and fix intermittents, >> but there will undoubtedly be some changes to our orange after landing this. >> >> If you have an intermittent you think appeared after this lands, please >> look for any possible timing races in the test. Also, feel free to NI me >> to help investigate. >> >> Again, I've worked hard to squash the intermittents I've seen in try, so >> I don't believe there will be any super frequent failures from this bug. >> (Or I wouldn't be landing, etc...) >> >> Please let me know if there are any questions or concerns. Thanks! >> >> Ben >> >> [1] For example, using this tool: >> >> https://people-mozilla.org/~bkelly/timeout-precision/?mode= >> delta&delay=10&count=100 >> >> My current FF55 on windows 10 gives the following stats for "differences >> from specified firing time" in milliseconds: >> >> min:-0.120 mean:1.922 median:1.830 max:5.180 stdev:1.753 >> >> So sometimes it fires as much as 120us early and has a median firing time >> 1.8ms late. With bug 1363829 we get: >> >> min:0.010 mean:0.403 median:0.025 max:4.155 stdev:1.098 >> >> So we don't fire early any more and our median firing time is only 25us >> late. >> > > _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
