> Also, is there a way to get numbers for the >> time from process launch to the point when we start loading the first URL
I think there is. There's this "startup timeline" stuff that we record timestamps for: http://searchfox.org/mozilla-central/rev/848c29538ab007fb95dc6cff194f0e3d3809613d/toolkit/components/startup/StartupTimeline.h#6-21 one of those things is firstLoadURI, and I think that's what you want here. It's recorded here: http://searchfox.org/mozilla-central/rev/848c29538ab007fb95dc6cff194f0e3d3809613d/docshell/base/nsDocShell.cpp#1283-1286 It looks like we do gather this telemetry from the content process: https://mzl.la/2lgY09x And I believe the value along the X axis is "roughly number of milliseconds since process start". In some cases, it seems that our performance is not amazing on that measurement either. Coincidentally, blassey just landed bug 1303096, which gets rid of a bunch of synchronous messages from content to parent on start-up. We might see a shift in those numbers as that change rolls out on Nightly. -Mike On 07/02/2017 12:57 PM, Gabor Krizsanits wrote: > Thanks a lot for these numbers! Also, is there a way to get numbers for the > time from process launch to the point when we start loading the first URL > in the new content process? We run a lot of frame and process scripts > sooner than we would get there, and I'm afraid we would get even worse > numbers that way, and that will affect user experience. (I'm not sure how > to filter the related telemetry based on "if the new tab is starting up a > new content process or not") > > For a temporary workaround until we can speed up content process start up > and initialization time, we might want to use the pre-allocated process > manager for the e10s-multi case. Maybe even force to pick one from the > existing processes unless there is one already available. > > Gabor > > On Tue, Feb 7, 2017 at 6:36 PM, Benjamin Smedberg <benja...@smedbergs.us> > wrote: > >> https://telemetry.mozilla.org/new-pipeline/dist.html#! >> cumulative=0&end_date=2017-02-06&keys=__none__!__none__!__ >> none__&max_channel_version=aurora%252F53&measure=CONTENT_ >> PROCESS_LAUNCH_TIME_MS&min_channel_version=null&product= >> Firefox&sanitize=1&sort_keys=submissions&start_date=2017- >> 01-26&table=0&trim=1&use_submission_date=0 >> >> This shows the distribution of times to launch a content process from the >> time we initially ask for it to the time we get back the first >> initialization message through IPDL. So this covers actual process launch >> in the OS, XPCOM startup, and other bootstrap. >> >> At first glance, this appears worrying to me: almost 25% of content process >> startups take more than 1 second, and the median is >700ms. And this is on >> nightly/aurora, which users typically have faster computers. >> >> There's a lot of potential noise here: we don't know what else is going on >> on the computer (maybe it's near boot and there's still a lot of system >> churn). But this time definitely can have an impact on how quickly Firefox >> is ready to load pages and therefore the impression that users have of its >> total speed. >> >> Soliciting everyone's opinion, but Harald's in particular: is it important >> to dive into this in more detail soon (before Firefox 57)? >> >> This metric is currently exploratory, and so I need guidance about whether >> it's important to keep this metric around for e.g. a release-health >> dashboard or to prevent regressions. >> >> --BDS >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
