We seem to execute content-sessionStore.js when loading a web page on a newly opened tab.
This shows up in profiles when loading for example youtube. The time is spent after navigation start but before first non-blank paint. It is possible that this won't help too much if we are anyhow just waiting for necko to feed the data to main thread.
We talked about this on IRC: http://logs.glob.uno/?c=content#c448568 From what I can tell, this seems like a problem due to the initial load of the first webpage in a new tab triggering our process switching logic (as currently about:newtab is loaded in the chrome process), and our chrome->content process swap code is really un-optimized and slow right now. The biggest impact of this bug (which is that the first page load in a tab is slower) should go away when activity stream is enabled, as activity stream is loaded in the content process, and no process swap will need to happen. This means that this occurring in a newly opened tab shouldn't happen any more. This combined with the complexity of rewriting our process swap code (which we definitely need to do at some point) means that I don't think this should be [qf:p1]. After activity stream ships, this should only impact people who are loading the webpage from a chrome-only page (like about:config or about:preferences), and people who are loading web URLs from a tab looking at a file URI. Neither of these seem like frequent enough situations to focus on.
Currently this shows up when doing Quantum Flow page load tests. But if activity stream ships soon enough, then I agree we shouldn't focus on this.
Given comment 2 and my understanding of Activity Stream's intention to ship soon-ish I'm going to make this qf:p3.
Whiteboard: [qf] → [qf:p3]
You need to log in before you can comment on or make changes to this bug.