Delay font cache building by few seconds to yield for startup resource contention.

chrome/browser/chrome_browser_main_win.cc

Index: chrome/browser/chrome_browser_main_win.cc
diff --git a/chrome/browser/chrome_browser_main_win.cc b/chrome/browser/chrome_browser_main_win.cc
index 3458df209274da8ea28e0234ff4bc4cd4454767b..1a93a3bf91216bd814cad6b139e6bece09978c73 100644
--- a/chrome/browser/chrome_browser_main_win.cc
+++ b/chrome/browser/chrome_browser_main_win.cc
@@ -249,9 +249,26 @@ void ChromeBrowserMainPartsWin::PostProfileInit() {
     // otherwise it will spawn utility process to build cache file, which will
     // be used during next browser start/postprofileinit.
     if (!content::LoadFontCache(path)) {
-      content::BrowserThread::PostTask(
-          content::BrowserThread::IO, FROM_HERE,
-          base::Bind(ExecuteFontCacheBuildTask, path));
+      // We delay building of font cache until first startup page loads.
+      // Selected 5 seconds as delay based on 50th percentile value
+      // for Startup.FirstWebContents.NonEmptyPaint.
+      // During first renderer start there are lot of things happening
+      // simultaneously some of them are:
+      // - Renderer is going through all font files on the system to create
+      //   a font collection.
+      // - Renderer loading up startup URL, accessing HTML/JS File cache,
+      //   net activity etc.
+      // - Extension initialization.
+      // We delay building of cache mainly to avoid parallel font file
+      // loading along with Renderer. Some systems have significant number of
+      // font files which takes long time to process.
+      // Related information is at http://crbug.com/436195.
+      const int kBuildFontCacheDelaySec = 5;

[gab, 2015/03/12 12:44:43]

I don't think 5s is enough.

From timelinev2:
https://uma.googleplex.com/timeline_v2?day_count=90&platform=W&version_tag=D&...

The median (50th percentile) is more around 8s on Beta (I don't think we can
rely on stats from M41 Stable just yet as it's not even @ 100% IIRC) and just
below 20s at the 75th percentile (which is the main percentile we're looking at
for the code purple).

Are there any benefits to starting this ASAP? If not, consider delaying it 30s+.

(also remember that "time to first paint" doesn't mean "time to tab responsive",
i.e. we don't want to flood with background tasks the second we managed to draw
a single frame)

[Shrikant Kelkar, 2015/03/17 23:32:23]

Modified delay to 30s

+      content::BrowserThread::PostDelayedTask(
+          content::BrowserThread::IO,

[gab, 2015/03/12 12:44:43]

Does this have to be on the IO thread? The IO thread's responsiveness is
extremely important, especially on startup. Looks like all
ExecuteFontCacheBuildTask is doing is launching a utility process, is the
PROCESS_LAUNCHER thread perhaps more appropriate for that?

[Shrikant Kelkar, 2015/03/17 23:32:23]

Most utility processes start on IO thread as after starting they need to send a
message to the process.

+          FROM_HERE,
+          base::Bind(ExecuteFontCacheBuildTask, path),
+          base::TimeDelta::FromSeconds(kBuildFontCacheDelaySec));
     }
   }
 }