For optimal performance, a renderer needs as many threads in the foreground pool as there are cores on the machine. RenderProcessImpl configures the number of threads in the foreground pool correctly for renderer processes. In the case where renderers live in the browser process, the code added by this CL adjusts the number of threads in the foreground pool of the browser process.
The associated bug is a perf regression on single-process android_webview caused by a migration of renderer tasks from base::WorkerPool (which can have an infinite number of threads) to the foreground pool of TaskScheduler (which :- has max(2, num_cores) threads in a renderer process- had x = min(8, max(3, 0.3 * num_cores)) threads in a browser process prior to this CL- has max(x, num_cores) in a --single-process browser process with this CL ).
Discussion about single-process on android_webview: https://groups.google.com/a/chromium.org/d/msg/android-webview-dev/QTFdKg0oR_U/K5f99jeCBAAJ
Bug: 727573 Change-Id: I2c6e1265dc9b39bddd66c0601683db702f943bda Reviewed-on: https://chromium-review.googlesource.com/521262 Commit-Queue: Francois Doray
6d3c64969 Increase number of foreground threads in --single-process browser process.
base/task_scheduler/task_scheduler.h | 16 ++++++++---
content/browser/browser_main_loop.cc | 24 ++++++++++++++--
content/browser/browser_main_loop.h | 3 ++
content/browser/browser_main_loop_unittest.cc | 41 +++++++++++++++++++++++++++
content/common/BUILD.gn | 2 ++
content/common/task_scheduler.cc | 15 ++++++++++
content/common/task_scheduler.h | 18 ++++++++++++
content/renderer/render_process_impl.cc | 6 ++--
content/test/BUILD.gn | 1 +
9 files changed, 118 insertions(+), 8 deletions(-)