Now might be a good time to try to bring up https://bugzilla.mozilla.org/show_bug.cgi?id=776798 again. Anything called from an nsITimerCallback from a JSM runs without the method JIT unless you explicitly set Components.utils.methodjit in the callback or use window.setTimeout on the hidden DOM window instead. This still happens in the latest Nightly.
I never heard back whether this was intentional or not, and this may not matter most of the time since often there's not much code running in the nsITimerCallback, but in our extension we got a ~30% speedup on some performance-critical code by setting Components.utils.methodjit back to whatever it was outside of the callback. Simon On Mar 2, 7:47 pm, Matt Brubeck <mbrub...@mozilla.com> wrote: > I noticed a number of places in Mozilla code where setTimeout-like > functionality is needed, but DOM window.setTimeout is not available > because the code runs in a non-DOM context like a JSM. In a few places > we had created pure-JS implementations of window.setTimeout to solve > this problem. > > With Gavin's encouragement, I extracted one of these into a standalone > JSM file, to make it easier to share. If you need to call setTimeout > without a DOM window, you can now use Timer.jsm: > > https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modu... > > This offers two main benefits over just using nsITimer directly: it > makes it easier to re-use code written for use in a DOM window, and it > addresses this common nsITimer garbage collection > problem:http://www.joshmatthews.net/blog/2011/03/nsitimer-anti-pattern/ > > For more details, see bug 840360. Thank you to Chris Jones who wrote > the original code, and to several other people who gave feedback on it. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
