build process - ver - ¿Cómo optimizar el tiempo de inicio de un script SCons?

ver tags de videos de youtube (6)

Añade a tu SConscript algo como

if ''explain'' in GetOption("debug"): Progress(''Evaluating $TARGET/n'')

y correr con --debug=explain . Verás lo que SCons dedica tiempo a evaluar.

Tengo una secuencia de comandos SCons que toma alrededor de 10 segundos para descubrir que no se necesita reconstruir nada, lo que se siente muy largo para lo que es esencialmente un proyecto bastante pequeño. La lectura del SConscript en sí toma solo uno o dos segundos, la mayor parte del tiempo se dedica a:

scons: Building targets ...

paso.

¿Cómo puedo saber qué hacen exactamente los scons en este momento? ¿Y qué otro consejo general se puede dar al escribir scripts de SCons rápidos?

Cuando SCons crea el primer Environment , realiza una serie de búsquedas para ver qué herramientas están disponibles. Puede evitar verificaciones innecesarias y acelerar el uso de SCons eligiendo explícitamente las herramientas en DefaultEnvironment antes de crear su primer env .

DefaultEnvironment(tools=[])

Hice un poco de prueba y error para descubrir por qué SCons es lento, hasta ahora, algunos resultados (los resultados exactos variarían dependiendo de la estructura y complejidad del script SCons):

CacheDir() no tiene un impacto negativo notable.
Decider() tiene un impacto muy pequeño, no vale la pena molestarse con él.
El uso de variant_dir / VariantDir() aumenta el tiempo de construcción en alrededor del 10%.
Leer el archivo SConstruct sí mismo toma alrededor del 10% de la llamada completa de los scons.
El mayor impacto parece ser la dependencia de la biblioteca, ya que Gtkmm en el proyecto duplicó el tiempo de compilación para mí.

Soluciones posibles:

No realice reconstrucciones completas, solo reconstruya el directorio / módulo en el que está trabajando ( scons -u lugar de scons -D ).
Haga que las partes de SConscript opcionales, de modo que solo se reconstruyan cuando se las llama manualmente.
Use la -isystem del compilador -isystem para bibliotecas incluidas en lugar de -I , solo este cambio redujo el tiempo de compilación de 10.5 seg a 6 seg. Para mí, se puede lograr fácilmente con una pequeña llamada sed:
env.ParseConfig(''pkg-config --cflags --libs gtkmm-2.4 | sed "s/-I/-isystem/g"'')

No exactamente seguro de por qué funciona esto, asumo que reduce las dependencias que genera gcc y, por lo tanto, las dependencias que scons rastrea.

El uso de CacheDir() y scons -j N es, por supuesto, también altamente recomendado, pero solo acelera la construcción en realidad, no la evaluación del script SCons en sí.

Trasladar a terceros incluidos fuera de CPPPATH y a CCFLAGS hizo una gran diferencia. Para nuestro proyecto con 12 directorios de inclusión externos (incluidos boost y python), una compilación de no hacer nada pasó de 30s a 3s, una aceleración de 10x.

scons md5-sums archivos para descubrir que han cambiado, por lo que prácticamente md5sums todos sus archivos.

Puede decirle que solo use marcas de tiempo para decidir qué reconstruir y no tener que MD5sumir todos los archivos cada vez, como lo hace ''make'', lo que debería acelerar el proceso. Podría ser más frágil. por ejemplo, si un archivo ha cambiado en 1 segundo desde la última vez que se compiló, los scons no lo notarán. Utilizar

env.Decider(''timestamp-newer'')

También hay una marca de tiempo MD5, que verificará primero la marca de tiempo, luego comparará el contenido con Md5 si realmente se modifica si la marca de tiempo es más nueva.

env.Decider(''MD5-timestamp'')

Otra opción fácil para acelerar las cosas es ejecutar la construcción paralela usando el parámetro -j.

scons -j 2

En mi caja de 2 núcleos, -j 3 usualmente da la mayor aceleración.

Algunos resultados sobre lo que están haciendo los scons se pueden hacer con el argumento --debug para llamar a los scons, consulte la página del manual de las diversas opciones.

(Robado directamente de )

El comando ''scons --max-drift = 1 --implicit-deps-sin cambios'' ejecutará tu compilación lo más rápido posible.

env.Decider (''MD5-timestamp''): a partir de SCons 0.98, puede configurar la función Decider en un entorno. MD5-timestamp dice si la marca de tiempo coincide, no te molestes en volver a MD5 en el archivo. Esto puede dar enormes aceleraciones. Vea la página del manual para más información.
--max-drift: de forma predeterminada, SCons calculará la suma de comprobación MD5 de cada archivo fuente en su compilación cada vez que se ejecute, y solo almacenará en caché la suma de comprobación después de que el archivo tenga 2 días de antigüedad. Este valor predeterminado de 2 días es proteger de la inclinación del reloj de los sistemas de control de revisión o NFS. Puedes modificar este retraso usando --max-drift = SECONDS donde SECONDS es un número de segundos. La disminución de los SEGUNDOS puede mejorar la velocidad de construcción al eliminar los cálculos de suma de comprobación MD5 superfluos. En lugar de especificar esto en la línea de comandos de cada ejecución, puede configurar esta opción dentro de su archivo SConstruct o SConscript usando "SetOption (''max_drift'', SECONDS)".
--implicit-deps-unchanged: Por defecto, SCons volverá a escanear todos los archivos de origen en busca de dependencias implícitas (por ejemplo, el encabezado de C / C ++ #includes), lo que puede ser un proceso costoso. Puede decirle a SCons que almacene en caché las dependencias implícitas entre invocaciones usando --implicit-deps-sin cambios. Al usar estas opciones, le está prometiendo a SCons que no cambió ninguna de las dependencias implícitas desde la última ejecución. Si cambia las dependencias implícitas, el uso de --implicit-deps-changed hará que se vuelvan a escanear y almacenar en caché. (No puede configurar esta opción desde dentro de los archivos SConstruct o SConscript).
--implicit-cache: esta opción le dice a SCons que almacene en forma inteligente las dependencias implícitas. Intenta determinar si las dependencias implícitas han cambiado desde la última compilación y, de ser así, las volverá a calcular. Esto suele ser más lento que usar --implicit-deps-sin cambios, pero también es más preciso. En lugar de especificar esto en la línea de comandos de cada ejecución, puede configurar esta opción dentro de su archivo SConstruct o SConscript usando "SetOption (''implit_cache'', 1)".
CPPPATH: normalmente le dice a Scons sobre los directorios de inclusión configurando la variable de construcción CPPPATH, lo que hace que los SCons busquen esos directorios cuando realicen exploraciones de dependencia implícitas y también incluyan esos directorios en la línea de comandos de compilación. Si tiene archivos de encabezado que nunca cambian o raramente cambian (por ejemplo, encabezados de sistema o encabezados de tiempo de ejecución de C), entonces puede excluirlos de CPPPATH e incluirlos en la variable de construcción CCFLAGS, lo que hace que los SCons ignoren esos directorios de inclusión al escanear Para dependencias implícitas. El ajuste cuidadoso de los directorios de inclusión de esta manera generalmente puede resultar en un aumento dramático de la velocidad con muy poca pérdida de precisión.
Evite las exploraciones RCS y SCCS utilizando env.SourceCode (".", None): esto es especialmente interesante si está utilizando muchos encabezados c o c ++ en su programa y que su sistema de archivos es remoto (nfs, samba).
Cuando use "BuildDir", utilícelo con "duplicate" establecido en 0: "BuildDir (dir1, dir2, duplicate = 0". Esto hará que los scons invocen a Builders usando los nombres de ruta de los archivos de origen en src_dir y los nombres de ruta de los derivados Sin embargo, esto puede causar problemas de compilación si los archivos de origen se generan durante la compilación, si alguna de las herramientas invocadas está codificada para colocar los archivos derivados en el mismo directorio que los archivos de origen.
En una máquina multiprocesador puede ser beneficioso ejecutar varios trabajos a la vez; use --jobs N (donde N es el número de procesadores en su máquina), o "SetOption (''num_jobs'', N)" dentro de su SConstruct o SConscript. En las máquinas con Windows, el número de procesadores está disponible en la variable de entorno ''NUMBER_OF_PROCESSORS''.
Si tiene más de unas pocas docenas de definiciones de preprocesador ("-DFOO1 -DFOO2") puede encontrar al usar --profile que SCons está pasando mucho tiempo en la función subst (), generalmente solo agregando la cadena -D a las definiciones una y otra vez. Esto realmente puede ralentizar las construcciones donde nada ha cambiado. Con más de 100 definiciones, vi un tiempo de compilación de no hacer nada de 35 a 20 años utilizando la idea descrita en "Guardar en caché el CPPDEFINES" en esta página.

Otro truco para hacer que las cosas sean más rápidas es evitar volver a vincular los programas cuando una biblioteca compartida se modificó pero no se reconstruyó. Ver SharedLibrarySignatureOverride