La compilación de código C++ es un proceso complejo, que ejecuta muchas herramientas de compilación en paralelo y, a menudo, se ejecuta durante mucho tiempo. Siempre es deseable hacerlo más rápido, pero también es un desafío comprender cuál sería la forma más efectiva de lograrlo.
Nos gustaría compartir algunas técnicas que usamos para obtener una imagen "más grande" de la construcción, así como herramientas que pueden ayudar a ver qué está tomando tiempo en una parte particular de la construcción. También hablaremos sobre las opciones de proyectos de MSBuild que pueden mejorar el paralelismo de la compilación sin sobrecargar el sistema, así como otras opciones (no inmediatamente obvias) que podrían afectar el rendimiento de la compilación.
Este blog es más como una lista de lo que está disponible actualmente, lleno de instrucciones y detalles. Algunas de las sugerencias deberían ser útiles para cualquier compilación de C++, pero la mayoría de las medidas y las opciones de ajuste son para proyectos basados en MSBuild (vcxproj).
Como cualquier mejora del rendimiento comienza con la medición, aquí estamos:mida su construcción.
Tenga en cuenta que el tiempo total de compilación puede variar bastante entre varias compilaciones idénticas en la misma máquina:el sistema se está ajustando a los procesos activos. Por lo tanto, si compara compilaciones antes y después de realizar algunos cambios en las opciones, es más confiable ejecutar la compilación varias veces y obtener el promedio. También es útil medir no solo el tiempo total de construcción, sino también obtener información más detallada, por lo que si obtiene un resultado sorprendente, puede averiguar por qué sucedió. Para MSBuild, recomendamos ejecutarlo en la línea de comandos y recopilar un registro binario.
Mida su tiempo de compilación con el resumen de rendimiento de MSBuild
Si su compilación está basada en MSBuild, lo primero que debe hacer al investigar el rendimiento de la compilación es ver qué proyectos y qué tareas/objetivos dentro de los proyectos están ocupando la mayor parte del tiempo de compilación. Los datos de resumen de rendimiento también son muy útiles para comparar compilaciones con diferentes opciones.
Para obtener un resumen de rendimiento de su compilación completa, puede hacer lo siguiente:abra un símbolo del sistema para desarrolladores (o MSBuild) y ejecute la compilación de su solución con las siguientes opciones (reemplace los valores de configuración y plataforma con los que realmente tiene su solución) :
msbuild /m /t:clean /p:Configuration="Debug";Platform="x86" YourSolution.sln msbuild /m /fl -flp:PerformanceSummary;v=q;LogFile=Perf.log /p:Configuration="Debug";Platform="x86" YourSolution.sln
La configuración de verbosidad “quet” o “mínima” (-flp:PerformanceSummary;v=q ) se recomienda ya que el inicio de sesión de la consola lleva un tiempo considerable. Pero puede establecer la verbosidad en otros niveles si desea más información de compilación en Perf.log. También puede agregar /detailedSummary para ver la utilización de los nodos msbuild.exe).
La misma información se puede extraer de un registro binario. Recomendamos crear registros binarios al investigar sus compilaciones. Para crear un registro binario, ejecute:
msbuild /m /t:clean /p:Configuration="Debug";Platform="x86" YourSolution.sln
msbuild /m /bl:build.binlog /p:Configuration="Debug";Platform="x86" YourSolution.slnPara extraer la información de rendimiento en Perf.log, ejecute:
msbuild -noconlog -flp:PerformanceSummary -flp:v=q build.binlog
ren msbuild.log Perf.logTambién puede habilitar "Tiempos de compilación" para proyectos de VC en el IDE configurando "Herramientas/Opciones/Proyectos y soluciones/Configuración de proyectos de VC++/Tiempos de compilación" ="Sí". Esto creará el resumen de rendimiento para cada proyecto, pero no para la compilación de la solución completa. Por lo tanto, usar la línea de comando es mejor para ver la "imagen completa".
En Perf.log encontrará los tiempos (en ms) que tomó construir la solución completa, cada proyecto (en orden creciente de tiempo) y el tiempo conmutativo de todos los objetivos y tareas (también en orden creciente de tiempo). Tenga en cuenta que el tiempo de compilación del proyecto y algunos objetivos (como el objetivo de ResolveProjectReferences) incluyen la espera para que se construyan los proyectos a los que se hace referencia. Puede usar la pestaña Línea de tiempo del visor binlog para ver si se crearon otros proyectos como parte de la construcción de un proyecto en particular.
Para una solución que contenga principalmente proyectos de C++, cl y link suelen ser las tareas que requieren la mayor parte del tiempo:
Project Performance Summary:
…
1100252 ms d:testMySolution.sln 1 calls solution build time (msbuild /m)
Task Performance Summary:
…
22495731 ms Link 250 calls
152500624 ms CL 250 calls El tiempo de la tarea es la suma de todas las veces que la tarea estuvo ejecutándose para todos los proyectos y, por lo tanto, puede ser mayor que el tiempo total de compilación. Para las tareas de CL y Link, su tiempo es muy similar al tiempo de cl.exe y link.exe.
Use Build Insights para ver el cronograma de compilación para cl.exe y link.exe
La mayor parte del tiempo de compilación de C++ generalmente se dedica al compilador. Para visualizar lo que sucede durante la compilación, ver los procesos que se ejecutan en paralelo y pivotar sobre las partes que toman la mayor parte del tiempo, puede usar la herramienta Build Insights.
Cambie las opciones para mejorar el rendimiento de compilación de C++
Hay muchos parámetros que pueden afectar el rendimiento de la compilación y diferentes bases de código pueden beneficiarse de diferentes conjuntos de opciones. Aquí hablaremos sobre el antivirus y la configuración del proyecto que son fáciles de cambiar y que potencialmente pueden mejorar en gran medida el rendimiento de su compilación.
1. Comprueba la configuración de tu antivirus
Las compilaciones de C ++ producen muchos archivos intermedios y, a menudo, vemos el sistema de archivos como un cuello de botella allí. Con su antivirus escaneando todos los resultados de compilación, el problema se amplifica enormemente.
Antivirus de Windows Defender excluye automáticamente la mayoría de las herramientas de compilación comunes cuando se encuentran en las ubicaciones de instalación predeterminadas. Pero si instala Visual Studio en una ubicación personalizada o usa muchas herramientas de compilación adicionales, el rendimiento de su compilación podría verse afectado.
Para ver si los análisis de Windows Defender están afectando su compilación, puede usar Performance Analyzer para Microsoft Defender Antivirus. La herramienta recopila datos mínimos para que pueda ejecutarla durante una buena parte de su compilación (generalmente, 10-20 minutos son suficientes) si no toda la compilación. Recomendamos cerrar todas las aplicaciones no relacionadas con la compilación antes de recopilar los datos para evitar ver procesos no relacionados con la compilación en el informe.
Para recopilar los datos y ver los procesos de compilación afectados:
- Abra un Windows PowerShell y ejecute:
New-MpPerformanceRecording -RecordTo MyBuild.etl - Reconstruya su código en el IDE o en la línea de comandos
- Después de que finalice la compilación (o después de 10 a 20 minutos), regrese a PowerShell y detenga la grabación presionando cualquier tecla
- En PowerShell ejecuta
Get-MpPerformanceReport -TopProcesses:20 MyBuild.etlEsto le dará la lista de los procesos afectados, similar a la siguiente:
TopProcesses ============ Count TotalDuration MinDuration AverageDuration MaxDuration MedianDuration ProcessPath ----- ------------- ----------- --------------- ----------- -------------- ----------- 8193 62272.1020ms 0.1790ms 7.6006ms 119.5682ms 6.8465ms D:Visual Studio 17VCToolsMSVC14.30.30528binHostx64x86cl.exe 1068 14587.9547ms 3.2531ms 13.6591ms 927.2716ms 6.0416ms D:Visual Studio 17VCToolsMSVC14.30.30528binHostx64x86link.exe …Puede agregar las herramientas de compilación desde las ubicaciones de confianza a la lista de archivos o directorios excluidos en la configuración de Windows Defender.
2. Redefinir el directorio TMP.
Durante la compilación, cl.exe crea un archivo tmp por cada fuente en la carpeta TMP. Cuando muchos procesos cl.exe se ejecutan en paralelo y crean simultáneamente una gran cantidad de archivos en la misma carpeta, genera mucho estrés para el sistema de archivos.
El uso de diferentes carpetas TMP para diferentes proyectos (y preferiblemente no en la unidad del sistema) a menudo hace que la compilación sea más rápida, especialmente en máquinas potentes con muchas CPU donde la E/S del disco y el sistema de archivos suelen ser un cuello de botella.
Planeamos abordar este problema en las futuras versiones de VS, pero mientras tanto, puede redefinir la variable de entorno TMP para que sea diferente para diferentes proyectos. Ver la propuesta Directory.Build.props muestra al final del blog.
3. Ajuste las opciones de compilación para un mejor paralelismo.
Muchas operaciones de compilación de C++ admiten la ejecución en paralelo. Una suposición general es que la compilación debe ser más rápida cuando se ejecutan más operaciones de compilación en paralelo. Esto es cierto, pero solo hasta el punto en que la compilación no supera la capacidad del sistema para distribuir los recursos de la máquina entre los procesos y los subprocesos.
La mayoría de las herramientas de compilación utilizan mucho la CPU, la memoria y el sistema de archivos. Dependiendo de la cantidad de archivos de origen, su tamaño y contenido, cualquiera de estos componentes puede ser un cuello de botella que impida que la compilación sea más rápida cuando se ejecutan más herramientas en paralelo. Cuando se alcanza un límite de recursos, ejecutar más operaciones de compilación en paralelo hará que la compilación sea más lenta, en lugar de más rápida, a veces de manera significativa. Por ejemplo, el msbuild /m + cl /MP El problema del uso excesivo de recursos se conoce desde hace bastante tiempo, pero recientemente se volvió más frecuente a medida que más y más computadoras tienen más de 32 CPU lógicas. El problema del paralelismo de compilación óptimo es bastante complejo ya que es difícil predecir por adelantado el uso de recursos de un determinado operación de compilación y prácticamente imposible predecir la disponibilidad real de recursos durante todo el tiempo de esa operación de compilación. Pero se pueden usar algunas heurísticas, al menos para la cantidad de procesos y subprocesos en ejecución.
Administrador de recursos de MSBuild
En VS 2019 16.10, MSBuild introdujo la administración de recursos entre procesos, que permite compilar partes (tareas) de diferentes proyectos comunicando su uso anticipado de CPU y limitando este uso si los recursos ya están reservados por otras partes de compilación. Todas las tareas de compilación de C++ que inician varios procesos (como cl.exe o herramientas de compilación personalizadas) o las que se sabe que usan muchos subprocesos (como link.exe) participan en esta comunicación.
La compatibilidad con MSBuild Resource Manager en proyectos de VC está disponible en VS 2019 16.11 y versiones posteriores. En VS 2022 17.0 estaba activado de forma predeterminada, pero descubrimos que esto afecta negativamente el rendimiento de compilación en algunas bases de código, por lo que en 17.2 lo desactivamos para evitarlo. Para activarlo, la siguiente propiedad debe definirse como una variable de entorno o como una propiedad de MSBuild para todos los proyectos (consulte el ejemplo de Directory.Build.props):
set UseMSBuildResourceManager=true
Si no usa /MP para su compilación actual, enciéndalo y pruébelo. Para afectar a todos los proyectos, defina la siguiente propiedad como una variable de entorno o como una propiedad de MSBuild para todos los proyectos (consulte el ejemplo de Directory.Build.props):
set CL_MP = true
De forma predeterminada, el Administrador de recursos de MSBuild permitirá que todas las tareas del proyecto utilicen un máximo de 2* (número de núcleos de CPU) simultáneamente. El límite de 2x núcleos (en lugar de solo 1x) está dictado parcialmente por la arquitectura actual del programador de MSBuild, pero también parece permitir un mejor rendimiento de compilación en promedio. La mayoría de las veces, la compilación utilizará menos de 2x CPU y, cuando lo haga, el sistema generalmente tolera bastante bien la sobresuscripción de 2x CPU, a menos que la compilación golpee otros cuellos de botella que no sean la CPU (consulte la sección Máquinas con muchos núcleos).
También hay un par de "perillas" para probar si el comportamiento predeterminado no es lo suficientemente bueno. Además de establecer la cantidad máxima de proyectos que se pueden construir en paralelo (msbuild /m:nProjects ), puede establecer las siguientes variables de entorno (no pueden ser propiedades de MSBuild) para modificar el comportamiento:
MSBUILDCORELIMIT=Ndonde N es el número máximo de núcleos que se asignarán a un proyecto. De forma predeterminada, es la cantidad de CPU lógicas en la máquinaMSBUILDNODECOREALLOCATIONWEIGHT= [0 – 100]0 % significa que los nodos de MSBuild no consideran el uso de CPU y 100 % significa que cada nodo de MSBuild se consideraría que usa 1 CPU. En las compilaciones de C++, el uso de la CPU de los procesos de MSBuild es pequeño en comparación con el uso de la CPU del compilador, por lo que 0 debería estar bien. Pero para soluciones mixtas de C# y C++, probablemente debería establecerse entre 50 y 100.
Si por algún motivo compilar con MSBuild Resource Manager es más lento para su compilación y no desea experimentar con otras opciones, puede deshabilitarlo configurando UseMSBuildResourceManager como falso.
MultiToolTask (MTT)
Otras opciones que se pueden usar para limitar la cantidad de procesos cl.exe que se ejecutan en paralelo se describen en Mejorar el paralelismo en MSBuild.
Para activar el modo MTT, establezca las siguientes propiedades como variables de entorno o como propiedades de MSBuild para todos los proyectos (consulte también el Directory.Build.props muestra a continuación):
set UseMultiToolTask=true
set EnforceProcessCountAcrossBuilds=true
Esto hará que la compilación inicie un proceso cl.exe separado para cada fuente C/C++ y limitará la cantidad de procesos cl que se ejecutan simultáneamente (en todas las compilaciones del proyecto) a CL_MPCOUNT , que se establece de forma predeterminada en el número de procesadores lógicos.
El modo MultiToolTask también se puede utilizar junto con el Administrador de recursos de MSBuild. Esto podría ser beneficioso para algunas compilaciones, ya que en lugar de solicitar al administrador de recursos de MSBuild los recursos disponibles solo una vez antes de iniciar el cl.exe /MP de nivel superior , la compilación lo preguntará antes de iniciar cl.exe para cada archivo fuente.
Tenga en cuenta que para proyectos con muchos archivos C/C++ pequeños y simples (es decir, cuando la compilación de archivos individuales no toma mucho tiempo), iniciar un proceso cl.exe separado para cada archivo generaría una sobrecarga notable. Por lo tanto, se recomienda usar esta opción cuando la mayoría de los archivos de origen son relativamente grandes y complejos.
En VS 2022, se agregó el nuevo modo experimental "ClServer" para abordar la sobrecarga de creación de procesos en el modo MTT mediante el uso de un modelo de servidor-cliente similar a cl.exe /MP . El servidor generaría procesos cl.exe de trabajadores y luego enviaría el trabajo a través de IPC. El servidor reside en el proceso de MSBuild, por lo que está sincronizado con el administrador de recursos mientras programa el trabajo dinámicamente, asignando más trabajadores o liberando recursos para escalar hacia abajo para lidiar con compilaciones de "polo largo".
Para habilitar este modo, la siguiente propiedad debe definirse como una variable de entorno o como una propiedad de MSBuild para todos los proyectos (consulte el ejemplo de Directory.Build.props a continuación):
set EnableClServerMode=true
Aumentar el paralelismo de compilación para proyectos nativos de C++ (experimental)
Esta opción es experimental y actualmente solo funciona para compilaciones de línea de comandos (no compatible con la compilación IDE).
De forma predeterminada, si el proyecto B hace referencia al proyecto A, la compilación del proyecto B no comenzará hasta que finalice la compilación del proyecto A. Esto tiene sentido para los proyectos administrados en los que deben existir ensamblados antes de que puedan usarse como referencias en la compilación.
Pero la compilación de código C++ nativo generalmente no usa ninguna salida de compilación de los proyectos a los que se hace referencia, solo lo hace el enlazador. Incluso con módulos C++20, donde la compilación usa las salidas de compilación (módulos) de los proyectos a los que se hace referencia, solo necesita esperar para que finalice el paso de compilación del proyecto al que se hace referencia, pero no es necesario esperar a que se complete el enlace.
Para permitir que el paso de compilación de los proyectos de referencia comience tan pronto como finalice el paso de compilación de los proyectos de referencia:
set BuildPassReferences=true
Para permitir la compilación paralela de todas las fuentes nativas a pesar de las referencias del proyecto (implica BuildPassReferences=true ):(Tenga en cuenta que este modo no funcionará si el código usa módulos C++ 20 creados como parte de la solución)
set AllowParallelCompileInReferencedProjects=true
Como estas opciones permitirían la ejecución simultánea de más partes de compilación, asegúrese de habilitar MSBuild Resource Manager y/o MultiToolTask con EnforceProcessCountAcrossBuilds .
La línea de comando debería verse así:
msbuild /p:Configuration=Debug;Platform= x64 /t:BuildGenerateSources;BuildCompile;BuildLink solution.sln
Cómo funciona:
De forma predeterminada, MSBuild inicia la ejecución de la compilación del proyecto después de que todos los proyectos a los que hace referencia terminan de compilarse. Cada compilación de proyecto de VC consta de objetivos BuildGenerateSources, BuildCompile y BuildLink ejecutados uno tras otro. Históricamente se denominan "pase de construcción".
La línea de tiempo de compilación predeterminada para dos proyectos donde ProjectB hace referencia a ProjectA parece
Cuando BuildPassReferences se establece en verdadero, BuildGenerateSources de un proyecto B el objetivo se ejecutará tan pronto como el BuildGenerateSources del proyecto A objetivo terminar la construcción. El BuildCompile del proyecto B el objetivo esperará el BuildGenerateSources del proyecto B objetivo para terminar de ejecutar, así como el BuildCompile del proyecto A objetivos Del mismo modo, el BuildLink de un proyecto B el objetivo esperará el BuildCompile del proyecto B el objetivo y el proyecto A BuildLink objetivo.
Entonces, con BuildPassReferences = true , la línea de tiempo de compilación se vería como
Cuando AllowParallelCompileInReferencedProjects es cierto, la compilación permitirá que incluso los mismos objetivos de los proyectos de referencia y referenciados se ejecuten en paralelo. Esto solo funcionará si un objetivo no utiliza resultados del mismo objetivo del proyecto al que se hace referencia. Tenga en cuenta que .lib y .implib se crean como parte de BuildCompile para que siempre estén disponibles para BuildLink .
BuildGenerateSources del proyecto B el objetivo se puede ejecutar al mismo tiempo que el BuildGenerateSources del proyecto A objetivo. El BuildCompile del proyecto B el objetivo esperará los BuildGenerateSources del proyecto B y del proyecto A objetivos para terminar de ejecutar. El BuildLink del proyecto B el objetivo esperará los BuildCompile del proyecto B y del proyecto A objetivos.
Entonces, con AllowParallelCompileInReferencedProjects=true la línea de tiempo se vería como
4. Sintonice fuentes, incluye y encabezados precompilados (PCH)
Para ver qué fuentes consumen la mayor parte del tiempo del compilador, use Build Insights. Esta herramienta lo ayudará a ver si agregar una inclusión particular al pch ahorraría mucho tiempo de compilación. También le permitirá ver la línea de tiempo de construcción.
Consulte la siguiente publicación de blog para ajustar los archivos PCH:Problemas y recomendaciones del encabezado precompilado (PCH)
Si sus archivos están bien aislados, también puede intentar usar compilaciones de Unity (Jumbo):Compatibilidad con archivos de Unity (Jumbo) en Visual Studio 2017 15.8 (Experimental)
5. Consideraciones especiales para máquinas con más de 64 CPU
Las siguientes recomendaciones se basan en las mediciones del tiempo de compilación realizadas en una máquina con Windows Server de 192 núcleos.
- Si está ejecutando Windows Server 2016 en una máquina de este tipo, se recomienda actualizarlo a WS2019. WS2016 no estaba optimizado para lanzar muchas (64+) instancias del mismo exe, lo que resultó en un bajo rendimiento de 64+ cl.exe ejecutándose juntos.
- Cuando use Windows Server 2019, asegúrese de que la verificación del antivirus no esté afectando su compilación y que el directorio TMP esté redefinido (es decir, siga las recomendaciones n.° 1 y n.° 2 de este blog, consulte el cuadro a continuación).
- Es probable que la compilación golpee el sistema de archivos y el cuello de botella de E/S del disco cuando se ejecutan muchas herramientas de compilación en paralelo. Si ha ajustado sus opciones de compilación para obtener el mejor paralelismo (n.º 3), pero aún observa una baja utilización de la CPU durante la compilación, es probable que la compilación esté experimentando un cuello de botella que no sea la CPU. Intente limitar la cantidad de proyectos que se ejecutan en paralelo, así como configurar
MSBUILDCORELIMITa un número más bajo; esto podría mejorar el rendimiento de la compilación.
En una de nuestras pruebas, creamos una solución generada que contiene 250 proyectos, 250 archivos cpp cada uno, sin referencias de proyectos. También se generó el código C++ y, ciertamente, bastante simple, conteniendo una clase por archivo, hasta 30 métodos cada uno.
El siguiente gráfico muestra los tiempos de compilación de esta solución con diferentes opciones de sistema y TMP. Cada barra corresponde al msbuild /m:[nProjects] tiempo de compilación, no se establecieron otras opciones. Como los proyectos de prueba no tenían referencias de proyectos, eso fue suficiente para lograr el mejor paralelismo. Cada serie contiene tiempos de compilación cuando la cantidad de proyectos creados en paralelo (y, por lo tanto, la cantidad máxima de instancias cl.exe que se ejecutan juntas) fue 10, 20, 30 , 40, 60, 80, 100, 120, 140, 160 y 180.
La configuración del sistema/TMP para cada serie es:
- Configuración predeterminada de WS2016
- Configuración predeterminada de WS2019, ubicación de instalación de VS personalizada (Defender activado, sin exclusiones, carpeta TMP predeterminada
c:users[username]AppDataLocalTemp) - WS2019* Las herramientas de compilación están excluidas del análisis de Defender. Carpeta TMP predeterminada, no excluida del análisis de Defender.
- WS2019** Las herramientas de compilación y la carpeta TMP predeterminada se excluyen del análisis de Defender
- WS2019*** Las herramientas de compilación están excluidas del análisis de Defender, TMP se establece en una ubicación específica del proyecto, diferente para cada proyecto.
Tenga en cuenta que en todas las series, el tiempo de compilación no mejoró mucho (e incluso empeoró) al compilar más proyectos en paralelo después de algún punto. Para esta solución en particular, construir solo ~40 proyectos en paralelo mostró los mejores resultados.
También probamos otras soluciones generadas con diferentes números de proyectos, código más largo, referencias de proyectos, etc. También usamos diferentes opciones de compilación, especialmente las que recomendamos usar en la sección 3. Las tendencias fueron bastante similares, aunque el número óptimo de procesos paralelos pueden diferir.
La compilación del código "real" suele llevar mucho más tiempo que la compilación de nuestros archivos pequeños y simples generados, por lo que el cuello de botella del sistema de archivos podría no ser tan pronunciado allí. Pero cambiar la configuración del antivirus y TMP también mejoró los tiempos de compilación, aunque no tanto.
Muestra de Directory.Build.props para establecer opciones para todos los proyectos
Crear Directory.Build.props en el directorio raíz para afectar a todos los proyectos bajo esta raíz. Este es un contenido de muestra de Directory.Build.props puede usar para probar diferentes configuraciones de compilación.
<?xml version="1.0" encoding="utf-8"?>
<Project>
<PropertyGroup>
<!-- To enable project specific directory for temporary files. -->
<UseProjectTMPDirectory>true</UseProjectTMPDirectory>
<!-- To enable MSBuild Resource Manager in VS 2019 16.11 (on by default in VS 2022) -->
<UseMSBuildResourceManager>true</UseMSBuildResourceManager>
<!-- Uncomment to enable MultiToolTask (MTT) mode. -->
<!--<UseMultiToolTask>true</UseMultiToolTask>
<EnforceProcessCountAcrossBuilds>true</EnforceProcessCountAcrossBuilds>-->
<!-- Uncomment to enable experimental MTT ClServer mode, available in VS 2022. -->
<!--<EnableClServerMode>true</EnableClServerMode>-->
<!-- Uncomment and change the value to control the maximum number of cl.exe processes running in parallel.
If using MTT without MSBuild Resource Manager, 10-20% oversubscription is often beneficial. -->
<!--<CL_MPCount>20</CL_MPCount>-->
<!--Uncomment to allow executing more build operations in parallel-->
<!--<BuildPassReferences>true</BuildPassReferences> -->
<!--<AllowParallelCompileInReferencedProjects>true</AllowParallelCompileInReferencedProjects> -->
</PropertyGroup>
<ItemDefinitionGroup>
<!-- Enable parallel compilation (cl.exe /MP) -->
<ClCompile>
<MultiProcessorCompilation>true</MultiProcessorCompilation>
</ClCompile>
<!-- Enable parallel execution of a custom build tool-->
<CustomBuild>
<BuildInParallel>true</BuildInParallel>
</CustomBuild>
</ItemDefinitionGroup>
<!-- Define project specific directory for temporary files -->
<Target Name="SetProjectTMPDirectory"
Condition="'$(UseProjectTMPDirectory)' == 'true'"
AfterTargets="SetBuildDefaultEnvironmentVariables">
<MakeDir Directories="$(IntDir)TMP"/>
<SetEnv Name ="TMP"
Value ="$(IntDir)TMP"
Prefix ="false">
</SetEnv>
</Target>
</Project>Envíenos sus comentarios
La construcción es un proceso complejo, y su desempeño depende de muchos factores y circunstancias. La construcción de diferentes bases de código en diferentes hardware se beneficiaría de diferentes configuraciones de construcción. Esperamos que pueda probar algunas de las opciones descritas en el blog y ver si mejoran su tiempo de compilación.
Si intenta alguna sugerencia, háganoslo saber, ¡nos encantaría saber de usted! Puede dejar sus comentarios a continuación o enviarnos un correo electrónico a [email protected].