I was just looking at this as well. This call stack occurs before invoking the message loop, and is delaying message loop start by 7.1%.

Will, it looks like you added the base::IsOnNetworkDrive check in 73d6faae235add2deebf2a634f0cd0939751a946. Can you evaluate whether we can reduce the cost of base::IsOnNetworkDrive, or avoid or delay its invocation from the Pepper code?

yes, I can take a look at this.

is it possible to get a percentile distribution of the time taken inside base::IsOnNetworkDrive - it's possible this is a small number of clients who really are running on a network drive skewing the mean. Is the mean calculated across 100% of population - can this be changed to e.g. 95 percentile?

This should go away once we only have a single site at which Flash is registered during the start-up; IMO the right thing to do is resolve  issue 628320 , after which we can get rid of the calls in chrome_content_client.cc; after that when we call RegisterPepperFlashWithChrome during start-up there won't be any pre-registered Flash plugin and we won't have to check IsOnNetworkDrive to figure out which one we prefer to load.*

*Unless there is a component update implementation available as well. But then that case will go away once there's no bundled Flash anymore.

The mean is calculated across 100% of the population. We don't currently have the ability to look at percentiles, but I can run a custom analysis to get the time distribution across all startups, at a ~10ms granularity.

indeed, changes described in #4 will remove this from the startup path. THe code might still have to be called somewhere though to distinguish between system flash at same version as user-updated component flash (in user data dir) that is on a network drive.

Looks like your intuition is correct -- the bottom 95%ile of users spend <10 ms in base::IsOnNetworkDrive, while the remaining 5% spend 2.87 seconds on average.

More precisely, the cutoff between <10 ms and >= 10ms is around the 99.5%ile.

fwiw 99.37% of profiles are not on a network drive (uma data), so this matches the data we are seeing from the profiler.

FYI, https://codereview.chromium.org/2251923002/ is expected to mostly resolve this. It will still happen for those .5% of users once per Flash update, but no longer on every startup. It may also still happen if the user has an up-to-date system-wide installation of Flash (and a profile on a network drive).

Don't see it in the UMA metrics for the latest canary.