Closed Bug 1380398 Opened 2 years ago Closed 2 years ago

10.98 - 12.74% ts_paint_webext (osx-10-10, windows10-64, windows7-32) regression on push 9dd2156225d334fc9c164017b7c5068273bfb7ca (Tue Jul 11 2017)


(WebExtensions :: General, defect, P1)

56 Branch


(firefox-esr52 unaffected, firefox54 unaffected, firefox55 unaffected, firefox56 fixed)

Tracking Status
firefox-esr52 --- unaffected
firefox54 --- unaffected
firefox55 --- unaffected
firefox56 --- fixed


(Reporter: jmaher, Assigned: kmag)



(Keywords: perf, regression, talos-regression, Whiteboard: triaged)

Talos has detected a Firefox performance regression from push:

As author of one of the patches included in that push, we need your help to address this regression.


 13%  ts_paint_webext windows10-64 opt e10s     848.92 -> 957.08
 12%  ts_paint_webext windows7-32 opt e10s      981.25 -> 1,103.50
 11%  ts_paint_webext osx-10-10 opt e10s        1,388.00 -> 1,540.42

You can find links to graphs and comparison views for each of the above tests at:

On the page above you can see an alert for each affected platform as well as a link to a graph showing the history of scores for this test. There is also a link to a treeherder page showing the Talos jobs in a pushlog format.

To learn more about the regressing test(s), please see:

For information on reproducing and debugging the regression, either on try or locally, see:

*** Please let us know your plans within 3 business days, or the offending patch(es) will be backed out! ***

Our wiki page outlines the common responses and expectations:
Component: Untriaged → WebExtensions: General
Product: Firefox → Toolkit
:kmag, I see you authored the patches in bug 1364768, can you take a look at this regression which appears to be on the webext only test.
Flags: needinfo?(kmaglione+bmo)
This also landed an improvement, alongside regressions from above:

== Change summary for alert #7861 (as of July 11 2017 23:20 UTC) ==


 78%  tp5n nonmain_startup_fileio windows7-32 opt e10s     29,614.42 -> 6,390.25
This is a timing issue. We were previously (accidentally) delaying most of WebExtension startup until after first paint because the IndexedDB queries took so long. Now, startup happens earlier, which is the intended behavior, but is less performant.

I haven't decided exactly what to do about this yet, but I'm probably going to tweak the last unlanded patch for that bug to delay most of initialization for all extensions except the ones with the webRequestBlocking permission.
Flags: needinfo?(kmaglione+bmo)
Whiteboard: triaged
:kmag Can you give an update for this issue?
Flags: needinfo?(kmaglione+bmo)
Yes, bug 1381687 and bug 1382329 should take care of most of the regression.

I'm looking into other potential optimizations before I consider delaying most of the extension load process again, since our actual startup performance overhead is much easier to track this way, and we won't ever be able to completely delay these things when extensions with blocking webRequest permissions are installed.
Flags: needinfo?(kmaglione+bmo)
Bug 1381687 already brought considerable, but still partial improvements on ts_paint_webext. Will wait for bug 1382329.
it looks like bug 1382329 has all r+ patches, we have 1 week until merge day, possibly we can have this landed and confirmed before then.
Priority: -- → P1
To be clear the numbers improved after the 26th which is when 1382329 landed.
Depends on: 1382329
Target Milestone: --- → mozilla56
Version: 53 Branch → 56 Branch
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.