TelemetryStartup can delay startup by up to 30 seconds with MSIX builds
Categories
(Toolkit :: Telemetry, defect)
Tracking
()
People
(Reporter: yannis, Unassigned)
Details
This profile was shared on Reddit by a user. It shows a long time (5 seconds) spent waiting on startup, where the biggest part of 3.7 seconds is presumably spent on WaitForSingleObject(event.get(), 30000);
in nsWindowsPackageManager::GetCampaignId
here, as part of TelemetryStartup
. This delay of 3.7 seconds (which could theoretically be up to 30 seconds in fact) seems unreasonable for something that blocks startup (or more generally the main thread).
[:bhearsum], is there any way that we could avoid waiting on the main thread here? Would it work to just move the waiting part outside of the MTA closure? (Maybe not if this is already on the main thread)
Comment 1•1 year ago
|
||
Ouch.
The reason we do this is to add attribution information to the Telemetry Environment. As I understand it, this is something that is known and expected to be in the critical path of start-up. (We do something similar for non-MSIX Windows builds as well, but it only relies on reading a file from disk - not an API like this.)
I imagine we could make this a non-blocking part of start-up for MSIX builds, and add it to the Telemetry Environment later (maybe as part of startup idle tasks?) -- but that would mean attribution information is not available as part of the first startup, and I'm not sure whether or not that's acceptable.
In any case, I don't work on this anymore, so I'll pass along the needinfo to someone who is more likely to be involved in fixing this.
Reporter | ||
Updated•1 year ago
|
Reporter | ||
Comment 3•1 year ago
|
||
Let's move the discussion the bug filed by the user.
Reporter | ||
Comment 4•1 year ago
|
||
It turns out we already had a filed bug for this.
Description
•