New performance monitoring mochitests added to Thunderbird

Mark Banner mbanner at
Fri Aug 28 21:43:22 UTC 2020

Earlier in the week, I added a couple of performance monitoring 
mochitests to Thunderbird:


These are both based on tests in Firefox under the same name.


This test records at which phase of the startup JS components and 
modules are first loaded.

The basic idea for modules is to load them as late as possible, or not 
at all if the function is not activated. Delaying loading of modules, 
means the earlier parts of startup can be done quicker, so that the 
first window starts to display and paints quicker. Delaying 
non-essential tasks until after the window has loaded also helps.

If you run the test, it will output all the modules currently loaded in 
the various phases.

The main things to note here:

  * Try not to use direct `ChromeUtils.import` - this loads a module
    straight away as soon as that line is hit. If you end up not using
    that module (because the function isn't hit), that's a waste of
    loading time.
      o The only time you really want to use this is where the module
        you're loading is used in the initial processing of what you're
        loading it into, e.g. for XPCOMUtils.jsm if you're going to use
        `XPCOMUtils.defineLazyModuleGetters` or something like that.
  * Instead, use `ChromeUtils.defineModuleGetter` or
    `XPCOMUtils.defineLazyModuleGetters` - these handle automatically
    lazy loading your modules when they are actually needed.
  * Note there are other useful functions in XPCOMUtils
    for defining various lazy getters for scripts, services, modules and
    more. Definitely worth checking out what's in there.

At the moment, at lot of modules are allowed after the profile 
selection, but really we should be looking at delaying as much as 
possible until after the window is open. Shifting things out of the 
startup list is a definitely bonus.

If you do move things out of startup, please consider adding them to one 
of the deny lists, so that they aren't accidentally regressed.


This test currently records how much preference getters are called for 
each preference. Preference access can be slow, and so calling them lots 
hurts performance.

Currently the tests only checks against startup - generally the limit is 
40 accesses before it will fail. There are some (mainly core) prefs, 
that are whitelisted for various ranges of accesses.

If you have something that is a call path where a preference is accessed 
a lot, then one of the best ways to avoid that is to use 
`XPCOMUtils.defineLazyPreferenceGetter`. This not only stores the value 
of your preference, it will also automatically register its own listener 
and update the value if the preference changes. Even better, you can 
also pass it a function to get your code to do something when the 
preference changes.

Please try not to regress this, using lazy preferences is easy, and 
avoids unnecessary overhead.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list