Ninja: Ninja 应该有办法通过 IPC 而不是 CreateProcess 触发编译

Windows 上的 CreateProcess 在最好的时候很慢，而 Chrome 开发人员经常发现自己不在最好的时候。 过去几年在 Chrome 构建中处理的一些进程创建/销毁问题包括：

1. 由于 Windows 回归，Chrome 构建在进程破坏期间遇到 UserCrit 锁定争用，导致构建速度减慢和在 goma 构建期间出现严重的鼠标卡顿。 在 Windows 中修复，修复最终传播到所有相关的 Windows 10 版本 (https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and-i-cant-move-my-mouse/)
2. 由于 gomacc.exe 间接拉入 gdi32.dll，Chrome 构建在进程破坏期间遇到了 UserCrit 锁争用，导致构建速度减慢和在 goma 构建期间出现严重的鼠标卡顿。 通过避免 gdi32.dll 在 gomacc 中修复。
3. 反恶意软件在 CreateProcess 中导致了大约 11 毫秒的回归，使得完整的 Chrome 构建不可能快于大约 10 分钟，并减慢所有构建。 通过禁用此反恶意软件来修复。
4. 问题 3 中至少有两个变体，包括未正确禁用或即使禁用仍具有开销 (MsMpEng.exe) 的其他反恶意软件。
5. Chrome 构建中的高进程创建率触发了 SCCM 中的错误，导致僵尸进程最终导致高达 32 GB 的内存丢失（https://randomascii.wordpress.com/2018/02/11/zombie-processes-are-吃你的记忆/)
6. 为 gomacc.exe 启用 App Verifier 以调查偶尔的堆损坏在日志文件创建中遇到了 O(n^2) 性能问题 (https://randomascii.wordpress.com/2018/10/15/making-windows-slower-第 2 部分流程创建/)

其他不影响 Chrome 构建的进程创建/销毁问题包括：

1. Chromium 的大型测试二进制文件在 Windows 中遇到了 O(n^2) CFG 性能错误，这导致 unit_tests.exe 在 Windows 10 上花费了大约 5 倍的时间。通过在测试二进制文件 (https://randomascii.txt) 中禁用 CFG 来修复。 wordpress.com/2019/04/21/on2-in-createprocess/)
2. clang-cl 单元测试在进程破坏期间遇到 UserCrit 锁争用，导致测试时间是 Windows 10 上应有的时间的 5 倍，并导致严重的鼠标卡顿。 通过避免拉入 gdi32.dll 来修复。

目前所有这些问题都得到了缓解，但 MsMpEng.exe 会导致非零开销，即使所有内容都在排除的文件夹中。 然而，需要持续努力保持所有 Chrome 开发人员的机器正确配置，并且由于需要许多排除来保持良好的构建性能而导致一些安全性损失。 还在不断努力检测和调查这些问题。

在某些时候，不再值得对 CreateProcess 风车倾斜，而是避免如此频繁地调用 CreateProcess。 可以教 ninja.exe 如何使用 IPC 与本地服务器进程通信，该进程将管理一个编译进程池（goma 和/或 clang-cl），以避免在构建过程中 99% 的 CreateProcess 调用。

这样做将降低 CreateProcess 的 CPU 成本，将从 ninja 中的序列化关键路径中删除 CreateProcess，将允许使用更少的排除项启用更多安全监控，并将为我们节省未来回归的成本（调查时间和构建时间） .

或者 ninja 可以多线程 CreateProcess 但这不是一个完整的解决方案。

在 ninja 中从 CreateProcess 切换到 IPC 显然不是正确的做法，但值得讨论。 原型已创建，因此应在此处共享测试结果。