Assigning to mfoltz@ (who own the code) for further triage.

When I search the uma data on that page I don't see any mention of OnDnsSdEvent. I can see it when I do a regex search for it but then I lose all context. It may be that I'm just not used to the UI.

> It causes a new renderer to be created, which seems wrong.

Extensions typically run in their own rendered so this is normal and expected, if I understand correctly.

Is this a regression or an observation about where the cost is coming from.

>>When I search the uma data on that page I don't see any mention of OnDnsSdEvent. I can see it when I do a regex search for it but then I lose all context. It may be that I'm just not used to the UI.

Just search for extensions. Then here are some functions you can follow ProfileManager::AddProfile -> ExtensionService::Init -> InstalledLoader::LoadAllExtensions -> ExtensionRegistrar::EnableExtension -> MdnsAPI::...

>>Extensions typically run in their own rendered so this is normal and expected, if I understand correctly.

This is happening during startup, which seemed weird to me.

>>Is this a regression or an observation about where the cost is coming from.

This was just an observation on glancing through Extension initialization data on the metrics page. It seemed wrong that a simple API was taking a long time during startup.

This is basically WAI.  The UMA link doesn't tell me much, but The Media Router component event page registers an event listener for DNS-SD service discovery of Cast devices.  When there's a change in state, it wakes up the event page which creates a renderer process.

Fortunately we are about to move Cast device discovery out of the event page and this will no longer occur.  See Bug 752604 to track this launch.

>> When there's a change in state, it wakes up the event page which creates a renderer process.

Just confirming, is this WAI for it to happen during Profile initialization/ExtensionService::Init?

I don't know why initializing the ExtensionService would cause a mDNS event handler to fire.

It may be an artifact of the mDNS API: it uses event filters defined in the app manifest; loading the manifest changes the registration of service types with the DNS-SD implementation; which in turn may trigger an event somewhere since the set of service types has changed.  That seems like a bug.

Regardless, we are going to remove our dependency on this API shortly.

Oh ok. Will add Bug 752604 as a blocker. Also, you can probably track and expect improvements to Extensions.ExtensionServiceInitTime, for the finch experiment.

We've removed extension use of mDNS in M64.  I looked at some of the metrics referenced in this bug as a followup.

Extensions.ExtensionServiceInitTime is slightly decreased from M63 to M64.

https://uma.googleplex.com/p/chrome/timeline_v2/?sid=e35d1b2b44fb900625928bdee7d12e08

I don't see any tasks related to extension service initialization in the sampling profiler for M66 dev channel.

https://uma.googleplex.com/p/chrome/callstacks/?sid=27d2e74323837f8f88eba2bddda3b7b5

If there are other tasks slowing down extension startup, they shouldn't be related to mDNS use in the Media Router extension.  I'll move myself to CC in case there are any followups I can help with.