Ninja: Ninja debería tener una forma de activar compilaciones a través de IPC en lugar de CreateProcess

CreateProcess en Windows es lento en el mejor de los casos, y los desarrolladores de Chrome a menudo no se encuentran en el mejor de los casos. Algunos problemas de creación / destrucción de procesos que se han abordado durante los últimos años en la compilación de Chrome incluyen:

1. Las compilaciones de Chrome golpean la contención de bloqueo de UserCrit durante la destrucción del proceso, lo que provoca una desaceleración de la compilación y un tartamudeo significativo del mouse durante las compilaciones de goma debido a una regresión de Windows. Corregido en Windows, el arreglo finalmente se propagó a todas las compilaciones relevantes de Windows 10 (https://randomascii.wordpress.com/2017/07/09/24-core-cpu-and-i-cant-move-my-mouse/)
2. Las compilaciones de Chrome golpean la contención de bloqueo de UserCrit durante la destrucción del proceso, lo que provoca una desaceleración de la compilación y un tartamudeo significativo del mouse durante las compilaciones de goma debido a que gomacc.exe tira indirectamente de gdi32.dll. Se corrigió en gomacc evitando gdi32.dll.
3. El software anti-malware provocó una regresión de ~ 11 ms en CreateProcess, lo que hizo imposible que una compilación completa de Chrome sea más rápida que ~ diez minutos y ralentice todas las compilaciones. Se corrigió deshabilitando este software anti-malware.
4. Al menos dos variaciones del problema número 3, incluido otro software anti-malware que no está correctamente deshabilitado o todavía tiene gastos generales (MsMpEng.exe) incluso cuando está deshabilitado.
5. La alta tasa de creación de procesos en la compilación de Chrome desencadenó errores en SCCM que provocaron procesos zombies que eventualmente llevaron a hasta 32 GB de memoria perdida (https://randomascii.wordpress.com/2018/02/11/zombie-processes-are- comiendo-tu-memoria /)
6. Habilitar App Verifier para gomacc.exe para investigar daños ocasionales en el montón encontró un problema de rendimiento O (n ^ 2) en la creación de archivos de registro (https://randomascii.wordpress.com/2018/10/15/making-windows-slower- parte-2-proceso-creación /)

Otros problemas de creación / destrucción de procesos que no afectaron las compilaciones de Chrome incluyen:

1. Los grandes binarios de prueba de Chromium encontraron un error de rendimiento de O (n ^ 2) CFG en Windows que hizo que unit_tests.exe tardara aproximadamente 5 veces el tiempo que debería en Windows 10. Se corrigió al deshabilitar CFG en los binarios de prueba (https: // randomascii. wordpress.com/2019/04/21/on2-in-createprocess/)
2. Las pruebas unitarias clang-cl golpean la contención de bloqueo de UserCrit durante la destrucción del proceso, lo que hace que las pruebas demoren 5 veces el tiempo que deberían en Windows 10 y provocan un tartamudeo significativo del mouse. Se corrigió evitando tirar de gdi32.dll.

Actualmente, todos estos problemas están mitigados, con la excepción de MsMpEng.exe que causa una sobrecarga distinta de cero incluso cuando todo está en carpetas excluidas. Sin embargo, se necesita un esfuerzo continuo para mantener correctamente configuradas las máquinas de todos los desarrolladores de Chrome, y cierta pérdida de seguridad debido a las muchas exclusiones necesarias para mantener un rendimiento de construcción decente. También hay un esfuerzo continuo para detectar e investigar estos problemas.

En algún momento, ya no vale la pena inclinarse hacia el molino de viento CreateProcess y, en su lugar, evitar llamar a CreateProcess con tanta frecuencia. A ninja.exe se le podría enseñar cómo usar IPC para comunicarse con un proceso de servidor local que administraría un grupo de procesos de compilación (goma y / o clang-cl) para evitar el 99% de las llamadas a CreateProcess durante una compilación.

Hacer esto reduciría el costo de CPU de CreateProcess, eliminaría CreateProcess de la ruta crítica serializada en ninja, permitiría habilitar más monitoreo de seguridad con menos exclusiones y nos ahorraría los costos (tiempo de investigación y tiempo de construcción) de regresiones futuras. .

Alternativamente, ninja podría CreateProcess con múltiples subprocesos, pero esta no es una solución tan completa.

Cambiar de CreateProcess a IPC en ninja no es claramente lo correcto, pero vale la pena discutirlo. Se ha creado un prototipo, por lo que los resultados de las pruebas deben compartirse aquí.