build: enable ThinLTO link-time optimization for the main binary

[MarshallOfSound]

Description of Change

Chromium's build system applies the thinlto_optimize_default config to every target by default. That config passes --lto-O0 (Windows: /opt:lldlto=0) to the linker, meaning no optimization is performed during the ThinLTO link step — it exists to keep developer links fast. Targets that want real link-time optimization must explicitly swap in thinlto_optimize_max, which Chrome does for its three main binaries (chrome_initial, chrome_dll on Windows, and chrome_framework on macOS).

Electron has never done this swap, so every release build of Electron that uses ThinLTO (Linux and Windows today; macOS once #51669 lands) links the main binary with --lto-O0, giving up cross-module inlining and most of the link-time benefit of PGO.

This change applies the same config swap to electron_app (Linux/Windows executable) and electron_framework (macOS framework), exactly mirroring what chrome/BUILD.gn does for its equivalent targets.

Performance impact (measured)

Speedometer 3.1, Linux x64 release build from main, interleaved benchmark rounds of 10 iterations each on the same machine:

Build	Score
Electron release build today (--lto-O0)	22.08 ± 0.19
Electron with this change (--lto-O2)	24.99 ± 0.79

+13.2% improvement. For reference, Chrome for Testing at the same Chromium version (150.0.7863.0) scores ~28.4 in the same environment, so this change closes roughly half of the gap between Electron release builds and Chrome.

Build cost

• The final ThinLTO link of the main binary becomes more expensive: observed ~8 min → ~15 min on a 64-core machine, peak link RAM ~38 GB.
• .text grows ~8.4% from more aggressive cross-module inlining — the same trade-off Chrome makes for its binaries.
• Component/testing builds (which don't use ThinLTO) are unaffected.

Related

• build: re-enable ThinLTO on macOS #51669 — complementary: without this change, macOS would still link at --lto-O0 once ThinLTO is re-enabled there; with it, that PR delivers full link-time optimization on macOS too.

Checklist

• I have built and tested this change
• I have filled out the PR description
• I have reviewed and verified the changes
• npm test passes
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Improved performance of Linux and Windows release builds by enabling ThinLTO link-time optimization for the main Electron binary.

[deepak1556]

Nice find, thanks!

[release-clerk]

Release Notes Persisted

Improved performance of Linux and Windows release builds by enabling ThinLTO link-time optimization for the main Electron binary.

[trop]

I have automatically backported this PR to "43-x-y", please check out #51820

[trop]

I have automatically backported this PR to "42-x-y", please check out #51821

[LifeIsStrange]

@MarshallOfSound this is wonderful, how about leveraging PGO builds too? in addition to LTO (and maybe BOLT like binary optimizers https://www.phoronix.com/news/Fedora-Idea-More-PGO-LLVM-BOLT
)

[FrankenApps]

@MarshallOfSound Thanks for this.
It substantially improved the performance of CPU bound JS code running in V8 for me.
Do you know where the missing performance compared to Chrome is left on the table (also taking the recent addition of PGO into account) and is it realistic that Electron may (almost) fully catch up?
I was always under the impression that Electron used the very same V8 Engine build that Chromium uses as well, so I was very surprised to find subpar performance. 😅