abbeyj
commented
7 years ago I'm experiencing a similar problem but it makes opening or closing even a single tab slow/janky. This makes Firefox almost unusable for me. Since this is no longer limited to just "close other tabs", perhaps it could be given a higher priority?
To capture a profile of this, I opened a new window and then within that window I opened 20 blank tabs with Ctrl+T and then closed them with Ctrl+W. https://perfht.ml/2sqhImB
Firefox becomes completely unresponsive for 8 seconds or so. A lot of time is spent in assemblePayloadWithMeasurements/payloadObj.threadHangStats<. Switching to the Combined Stacks view, the time under that is spent in SharedLibraryInfo::GetInfoForSelf() and the calls it makes to GetVersion() and LoadLibraryExW().
Perhaps threadHangStats was added recently or has become slower? I've only noticed this problem making things painfully slow for the last week or so.
Can the number of calls to assemblePayloadWithMeasurements be throttled somehow? Or maybe the answers from GetVersion() can be cached so the operation isn't so slow? Or Services.telemetry.canRecordExtended could be disabled for these pings to avoid the collection of threadHangStats?
Workarounds:
- Disable Test Pilot
- Disable the "Share Additional Data (ie Telemetry) option. A restart of Firefox is then required.
When performing the "close other tabs" interaction, we fire many sequential tabclose events. It seems like tabcenter submits a telemetry ping every time a tab is closed. According to this profile I took of closing 19 tabs (https://perfht.ml/2pe2cpF) it looks like we're spending about half of the time which it takes to close 19 tabs sending telemetry pings. In my case, ~2 seconds were spent sending pings over the course of the ~3.5 seconds of tab closing.
In the situation where we're performing "close other tabs" we really ought to wait for all of the tabs to close before sending any pings.