RE does this survive restarts: yes and no. It's a bit sporadic. I'm wondering if this is just me occasionally getting unlucky and having expensive operations coincide with new-window operations? (e.g. the GC in the original comment). I just captured a perf profile right now (after a recent browser restart) with 4 new-window operations. The first had a `FX_NEW_WINDOW_MS` of `550ms`, and then there were two that were ~`240ms` and one that was `284ms`. Here's that profile: https://share.firefox.dev/47IuOfy A few things that I notice: Specifically with today's perf-profile, during the longest `FX_NEW_WINDOW_MS` operation, looking at the main thread in the parent process: (1) `Task places::NotifyIconObservers` occupies `180ms` of the parent-process time (2) `services-sync` (i.e. Firefox Sync operations) occupies `33ms` I suspect those two ~expensive operations (plus maybe some related overhead that's alongside them) are chiefly responsible for the difference between this long new-window operation vs. the shorter ones. For completeness, here are some other sections that are responsible for about the same amount of time in all of the new-window operations in all of the performance profiles here (the one from comment 0, second one in comment 3, and the one in this comment here): - 40ms in `L10nReadyHandler::ResolvedCallback` - 30ms in `ExtensionParent.sys.mjs` doing `recvAPICall` - 30ms in `nsWindow::UpdateMozWindowActive` - 19ms in `mozJSSubScriptLoader::LoadSubScript` (38ms in my longest new-window operation from today's profile) - 11ms in `RestyleManager::ProcessRestyledFrames` - 10ms in `NS_NewXULElement` - 9ms in `gtk_widget_render` to paint the new window - 4ms in `resource:///modules/BrowserUsageTelemetry.sys.mjs` (mostly `getOpenTabsAndWinsCounts`) These add up to 153ms, and are the main buckets that I could find of identifiable always-performed work in all of these operations. Maybe these (plus a bit more) represent a ~baseline for just-how-long-it-takes? (Some of these, e.g. the restyle and UpdateMozWindowActive operations, might be variable-cost -- scaling with how many tabs you've got open in the newly-backgrounded window which need to be repainted with an unfocused color, perhaps.)
Bug 1866145 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
RE does this survive restarts: yes and no. It's a bit sporadic. I'm wondering if this is just me occasionally getting unlucky and having expensive operations coincide with new-window operations? (e.g. the GC in the original comment). I just captured a perf profile right now (after a recent browser restart) with 4 new-window operations. The first had a `FX_NEW_WINDOW_MS` of `550ms`, and then there were two that were ~`240ms` and one that was `284ms`. Here's that profile: https://share.firefox.dev/47IuOfy A few things that I notice: Specifically with today's perf-profile, during the longest `FX_NEW_WINDOW_MS` operation, looking at the main thread in the parent process: (1) `Task places::NotifyIconObservers` occupies `180ms` (2) `services-sync` (i.e. Firefox Sync operations) occupies `33ms` I suspect those two ~expensive operations (plus maybe some related overhead that's alongside them) are chiefly responsible for the difference between this long new-window operation vs. the shorter ones. For completeness, here are some other sections that are responsible for about the same amount of time in all of the new-window operations in all of the performance profiles here (the one from comment 0, second one in comment 3, and the one in this comment here): - 40ms in `L10nReadyHandler::ResolvedCallback` - 30ms in `ExtensionParent.sys.mjs` doing `recvAPICall` - 30ms in `nsWindow::UpdateMozWindowActive` - 19ms in `mozJSSubScriptLoader::LoadSubScript` (38ms in my longest new-window operation from today's profile) - 11ms in `RestyleManager::ProcessRestyledFrames` - 10ms in `NS_NewXULElement` - 9ms in `gtk_widget_render` to paint the new window - 4ms in `resource:///modules/BrowserUsageTelemetry.sys.mjs` (mostly `getOpenTabsAndWinsCounts`) These add up to 153ms, and are the main buckets that I could find of identifiable always-performed work in all of these operations. Maybe these (plus a bit more) represent a ~baseline for just-how-long-it-takes? (Some of these, e.g. the restyle and UpdateMozWindowActive operations, might be variable-cost -- scaling with how many tabs you've got open in the newly-backgrounded window which need to be repainted with an unfocused color, perhaps.)