1958410 - [meta] Never block the parent process main thread for more than 5ms at a time, during applink startup

Status: NEW

(Core :: Performance Engineering, task)

Description

[Markus Stange [:mstange]]

To speed up applink startup (bug 1945906), the number one priority is to kick off the web request to the server for the applink URL as early as possible, and to consume the data it sends back immediately. At the moment, this requires bouncing a lot of coordination work through the parent process main thread, via various runnables, see e.g. bug 1956964 and bug 1956967.

Moving the networking stuff off the main thread is the right long term fix.

In the shorter term, we should find workarounds. This bug is about one such workaround: Make sure that the main thread does not delay any network runnable by more than 5ms, by making sure that no runnable / task / "macrotask" hogs the thread for more than 5ms at a time.

---

The currently known main offenders during applink startup are (times from https://share.firefox.dev/43ySyn1 ):

• 200ms geckoview.xhml DOMContentLoaded event, creating the <browser> for the tab (bug 1958065 and bug 1958097)
• 132ms dummy.xhtml load event, creating the <browser> for the WebExtensions background page (bug 1958327)
• 113ms IndexedDB complete event when listing translations (bug 1958042)
• 61ms of microtasks (within one uninterruptible macrotask) during some WebExtension startup work (to be filed)
• 47ms of microtasks (within one uninterruptible macrotask) with some more WebExtension stuff (to be filed)
• 28ms of DelayedInit work (to be filed)