Heads up to explain the sudden jump on Linux Startup perf test. I just submitted r32264 which makes opening and closing processes happen off the UI thread. Surprisingly enough, according to UMA stats these would take an average of 1s on Linux for the first renderer, and 100ms on Windows. Subsequent launches were very quick on Linux, but on Windows averaged 50ms. When using session restore with many tabs, this would block the UI thread for quite a bit. Also, Linux had code which might sleep for up to 2s on the UI thread waiting for the process to die.
Linux Warm Startup<http://build.chromium.org/buildbot/perf/linux-release-hardy/startup/report.html?history=150&graph=warm>perf test is showing a big regression (200ms->300ms). With Elliott's insight, I tracked this down to the fact that the UI thread is very busy at startup handling GTK messages, so the posted task back to it to tell BrowserRenderProcessHost that the handle is available is queued up. This parallelization is exactly what we want though, and the Linux New Tab Cold<http://build.chromium.org/buildbot/perf/linux-release-hardy/new-tab-ui-cold/report.html?history=150>test went from ~615ms to ~440ms. It's hard to see a change on Linux Warm Startup<http://build.chromium.org/buildbot/perf/linux-release-hardy/startup/report.html?history=150&graph=cold> because of all the noise. As for other platforms: Mac Startup<http://build.chromium.org/buildbot/perf/mac-release-10.5/startup/report.html?history=150&graph=warm> (both warm and cold) went from around 307ms to 290ms, while Mac New Tab Cold <http://build.chromium.org/buildbot/perf/mac-release-10.5/new-tab-ui-cold/report.html?history=150> went from 720ms to 620ms. Windows didn't have much change. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
