Tengo un proyecto que tarda unos 8 segundos para vincular con g ++ y ld.Consejos para reducir el tiempo de vinculación de C++
Utiliza un conjunto de bibliotecas estáticas, la mayoría del código es C++.
Me interesa una lista general de consejos sobre cómo reducir el tiempo de enlace. Cualquier cosa, desde "dont incluir símbolos de depuración" para "hacer que su código sea menos espagueti"
He tratado esto durante años en un trabajo anterior. El enlazador GNU simplemente tiene serios problemas de rendimiento al vincular grandes cantidades de bibliotecas estáticas. En un momento dado, el tiempo de enlace estaba a la par con el tiempo de compilación, lo cual nos pareció tan extraño que realmente investigamos esto y lo descubrimos.
Puede intentar combinar sus bibliotecas estáticas en un "superobjeto" antes de vincularlas. En lugar de vincular de esta manera:
$ g++ -o program program.o $STATIC_LIBS
Usted podría intentar esto:
$ ld -r -o libraries.o --whole-archive $STATIC_LIBS
$ g++ -o program program.o libraries.o
Tenga en cuenta que este método da el enlazador menos oportunidades para excluir el código objeto sin usar, por lo que los binarios pueden aumentar de tamaño un poco.
Si utiliza este método para el código de C++, es posible que necesite el modificador '-Ur' en lugar de' -r' (consulte la documentación de 'ld') – anatolyg
¿Existe una solución de osx para -Ur para el código de C++? parece que ld en osx10.6 no reconoce -Ur –
Al ver esto me pregunto si vincular dependencias primero daría un mejor rendimiento. – Alex
8 segundos es bastante rápido , a menos que esté muy seguro de que no debe tomar mucho tiempo. Tengo proyectos que tardan de 5 a 8 minutos en volver a vincularse por completo, ya que no realizamos enlaces incrementales en nuestras versiones de lanzamiento. ¿Ha intentado usar enlaces incrementales (si no está usando -shared, puede usar -i o -r)?
5-8 minutos todavía se ve como una gacela. –
@Martin: No es así, trabajo en una base de código LOC C++ de 1.2mill, que usa Boost, GMP y algunas otras bibliotecas desagradables, usando buen diseño, discc (8 servidores), discos rápidos, etc., una compilación completa de la base de código completa (incluyendo pruebas) toma alrededor de 2-2.5 minutos usando gcc 4.4 - Entonces, para que algo tome 8mins, tendría que ser una base de código muy mal escrita o enorme. –
o no se ejecuta en un servidor rápido ... – Jay
Desactive la optimización de todo el programa (al menos durante el desarrollo). Use p-impl para reducir dependencias.
no se supone p-impl para reducir el * compile * time? – Simone
@Simone: p-impl significa que los cambios en la implementación de una clase requieren recompilar solo esa única unidad de compilación en lugar de todos los consumidores. Menos unidades de compilación modificadas hace que los enlaces incrementales sean más efectivos. –
¿Qué hay de compilar las compilaciones de depuración como bibliotecas compartidas? Eso resolverá la saturación del símbolo de depuración, ya que las bibliotecas de importación son pequeñas con o sin información de depuración. Tal vez no sea la mejor solución, pero creo que esto reducirá sustancialmente el tiempo de enlace ...
Dijo específicamente que las bibliotecas compartidas estaban fuera. Y estoy de acuerdo con él: en los sistemas modernos, las bibliotecas compartidas añaden muchos problemas potenciales y le dan pocas ventajas. –
@TomSwirly En ninguna parte puedo ver que menciona estar en contra de las bibliotecas compartidas. – rubenvb
crear un ramdisk, compilarlo y vincularlo al disco duro.
ya que está utilizando una gran cantidad de bibliotecas estáticas, puede crear una biblioteca gigante que contenga todas estas bibliotecas para que termine con una biblioteca. elimine todas las bibliotecas de su lib-list y agregue el gigante. Esto reduce las aperturas de archivo a 1 para las bibliotecas y puede acelerar las acciones de lectura.
¿No es esto ramdisk lo que utilizamos en la década de 1980? – anatolyg
@anatolyg: Sí, pero aún supera a los discos duros. –
¡Tiene una SSD! –
¿Está usando [generación de código de tiempo de enlace] (http://gcc.gnu.org/wiki/LinkTimeOptimization)? Producirá código más rápido, pero los tiempos de enlace subirán. –
8 segundos es rápido. Eso no parece mucho de qué preocuparse. ¿Qué tan grande es el proyecto? –
Plataforma y compilador? Con GCC y binutils, [gold] (http://sourceware.org/ml/binutils/2008-03/msg00162.html) es más rápido que (clásico) ld y [clang] (http: //clang.llvm .org /) puede (o no) ser más rápido que eso. – ephemient