The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6928fde34e9a06b3079d0e5fcc4593bce2f466e1

commit 6928fde34e9a06b3079d0e5fcc4593bce2f466e1
Author: Sadrul Habib Chowdhury <sadrul@chromium.org>
Date: Fri Apr 20 16:02:51 2018

renderer: Start tile-worker threads asynchronously.

According to the sampling profiler, starting these threads take up
10% of the non-idle startup time on Win10 and Win8 (~5% on Win7).
Try starting these threads asynchronously instead.

To allow for this, turn Start() and Join() on base::SimpleThread into
non-virtual methods. Introduce BeforeStart() and BeforeJoin() virtual
methods so that tests can still do additional work as needed. Then,
introduce base::SimepleThread::StartAsync(), and use that for starting
the raster threads. Also introduce a BeforeRun() virtual method, so
that it is still possible to trigger some tasks after the thread has
been started and initialized asynchronously.

BUG= 835316 

Change-Id: I107c5cc5cf1dd579d2866a1feca6fd583b8f5577
Reviewed-on: https://chromium-review.googlesource.com/1015236
Commit-Queue: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#552344}
[modify] https://crrev.com/6928fde34e9a06b3079d0e5fcc4593bce2f466e1/base/threading/simple_thread.cc
[modify] https://crrev.com/6928fde34e9a06b3079d0e5fcc4593bce2f466e1/base/threading/simple_thread.h
[modify] https://crrev.com/6928fde34e9a06b3079d0e5fcc4593bce2f466e1/content/renderer/categorized_worker_pool.cc
[modify] https://crrev.com/6928fde34e9a06b3079d0e5fcc4593bce2f466e1/content/renderer/categorized_worker_pool.h
[modify] https://crrev.com/6928fde34e9a06b3079d0e5fcc4593bce2f466e1/content/renderer/render_thread_impl.cc
[modify] https://crrev.com/6928fde34e9a06b3079d0e5fcc4593bce2f466e1/ppapi/proxy/tracked_callback_unittest.cc

I will revisit in a week to see if this actually made a difference.

The profiler-difference between 68.0.3401.0-Canary and 68.0.3402.0-Canary show approx. 70.5ms improvement, or 8.5%, in renderer-process main-thread non-idle startup time (specifically, in content::RenderThreadImpl::Init()) : https://uma.googleplex.com/p/chrome/callstacks/?sid=3d032fa5512bda625b115a02ee0939a1

This aligns with my expectation. So I think I am going to close this as fixed.

/cc'ing a few folks who may be interested. We still don't have an owner for v8-stack unwinding for the sampling profiler to work with v8 stacks *hint* :) https://bugs.chromium.org/p/chromium/issues/detail?id=788808#c19

+Maria

What's the status of mobile startup benchmarks? Is there a benchmark we should run via a tryjob to get a sense of overall impact here?

experimental.startup.android.coldish is our latest and greatest, though we haven't switched system health away from start_with_url.{cold, warm}.startup_pages yet. Both are pretty short benchmarks, so you could try them both. I don't know if the new one is available via a tryjob yet, though.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/15869419c40000

📍 Job complete. See results below.
https://pinpoint-dot-chromeperf.appspot.com/job/15869419c40000

The NextAction date has arrived: 2018-04-27