build: consume Electron-generated PGO profiles in release builds
Official release builds currently apply Chrome's published PGO profile.
PGO profiles match functions by symbol name and control-flow hash, so
every function that differs from Chrome - all of Node.js, patched
Chromium files, V8 built with Node's flags, and the Electron shell -
silently gets no optimization guidance and is laid out as cold. The same
applies to V8's builtins profile: Chrome's published profiles reject
Electron's promise/async builtins because the Node.js integration
changes their codegen.
This change points release builds at Electron-generated profiles served
from the build-tools storage account instead:
- build/pgo_profiles/<target>.pgo.txt state files name the profile each
target consumes; updating profiles only changes these files.
- gclient hooks download the named profiles via
script/pgo/download-profiles.py.
- A small Chromium patch teaches the standard chrome_pgo_phase = 2
resolution to read Electron's state files (including per-arch Linux
profiles, which upstream does not have). Keeping Chromium's own PGO
configuration authoritative means every compiler and linker flag they
maintain - -fprofile-use, warning suppressions, extended-TSP block
layout, and anything they add in the future - applies to Electron's
profiles unchanged. An explicitly set pgo_data_path still takes
precedence as an override.
- Chrome's published profiles are no longer downloaded
(checkout_pgo_profiles is now False).
chrome_pgo_phase already defaults to 2 for official builds, so a single
release.gn import works for every platform/arch with no per-platform
configuration.
Measured against Chrome's profiles (Linux x64, otherwise identical
builds): +9.5% on Speedometer 3.1, +16% geomean across 22 app-operation
benchmarks, with contextBridge calls +44-51%.
6b2354f7dc