Digamos que tengo un binario que estoy compilando, e incluyo un montón de archivos que en realidad nunca se usan, y hago el enlace posterior a las bibliotecas descritas por esos archivos de inclusión. (nuevamente, estas bibliotecas nunca se usan)¿Cuáles son las consecuencias negativas de incluir y/o vincular cosas que su binario no usa?
¿Cuáles son las consecuencias negativas de esto, más allá del aumento en el tiempo de compilación?
Algunos se me ocurre son contaminación espacio de nombres y tamaño binario
Además de lo que Sasha listas es coste de mantenimiento. ¿Podrás detectar fácilmente qué se usa y qué no se usa en el futuro cuando y si eliges eliminar material no utilizado?
Además del tiempo de compilación; Mayor complejidad, distracción innecesaria durante la depuración, una sobrecarga de mantenimiento.
Aparte de eso, nada.
Si las bibliotecas nunca se utilizan, no debe haber un aumento en el tamaño del ejecutable.
+1, no hay ninguna razón para que el vinculador agregue archivos de objetos a los que no se haga referencia en ningún lugar. –
Pero solo si el enlazador puede garantizar que los objetos no estén referenciados desde otra unidad de compilación/biblioteca. Ahora el enlazador elimina los objetos de las bibliotecas vinculadas estáticamente que no se usan explícitamente (por lo tanto, el orden del enlace es significativo) pero NO del cuerpo ejecutable principal. –
El orden de enlace para los enlazadores de UNIX suele ser significativo y es posible que tenga que vincular la misma lib varias veces precisamente porque son (¡demasiado!) Buenos para eliminar los símbolos sin referencia –
Dependiendo del enlazador exacto, también puede observar que los objetos globales de sus bibliotecas no utilizadas aún se construyen. Esto implica una sobrecarga de memoria y aumenta los costos de inicio.
+1, interesante. ¿Tiene el estándar de C++ una postura sobre esto? –
Sí, "inicializar antes de la primera llamada de una función en el .cpp que define el global". "Cuando la biblioteca se carga" es un momento así, y fácil de detectar. – MSalters
Ah gracias. Sí, de acuerdo con eso, es legal (a) no construirlo en absoluto, ya que no se invocarán funciones en ese archivo fuente; o (b) construirlo en cualquier momento. Yuck :( –
Nunca he tenido problemas para vincular un archivo .lib del cual solo se usa una parte muy pequeña. Solo el código que realmente se usa se vinculará con el ejecutable, y el tiempo de enlace no aumentó notablemente (con Visual Studio).
Si enlaza con binarios y se cargan en tiempo de ejecución, pueden realizar una inicialización no trivial que puede hacer cualquier cosa, desde asignar una pequeña cantidad de memoria para consumir recursos escasos para alterar el estado de su módulo de maneras que no t esperar, y más allá.
Será mejor que se deshaga de cosas que no necesita, simplemente para eliminar un montón de incógnitas.
Si las bibliotecas que está incluyendo pero no está utilizando no están en el sistema de destino, no podrá compilar aunque no sean necesarias.
Here es mi respuesta para una pregunta similar sobre C y bibliotecas estáticas. Quizás también te sea útil en el contexto de C++.
Menciona un aumento en el tiempo de compilación. De eso entiendo que las bibliotecas están vinculadas estáticamente, y no dinámicamente. En este caso, depende de cómo el vinculador maneja las funciones no utilizadas. Si los ignora, tendrá principalmente problemas de mantenimiento. Si se incluirán, el tamaño del ejecutable aumentará. Ahora, esto es más significativo que el lugar que ocupa en el disco duro. Los archivos ejecutables grandes podrían correr más lento debido a problemas de almacenamiento en caché. Si el código activo y el código no activo son adyacentes en el exe, se almacenarán en caché, haciendo que el caché sea más pequeño y menos eficiente.
VC2005 y superior tienen una optimización llamada PGO, que ordena el código dentro del ejecutable de una manera que asegura el almacenamiento en caché eficaz del código que se utiliza a menudo. No sé si g ++ tiene una optimización similar, pero vale la pena investigar eso.
Un poco aquí la compilación de los temas, wiki-editar según sea necesario:
El problema principal parece ser: Espacio de nombres Contaminación Esto puede causar problemas en el futuro depuración, control de versiones, y el aumento de mantenimiento en el futuro costo.
También habrá, como mínimo, Binary Bloat, ya que se mantendrán las referencias de función/clase/espacio de nombres (¿en la tabla de símbolos?). Las bibliotecas dinámicas no deberían aumentar en gran medida el tamaño del binario (¿pero se convierten en una dependencia del binario para ejecutarse?). A juzgar por el compilador C de GNU, las bibliotecas vinculadas estáticamente no se deben incluir en el binario final si nunca se hace referencia a ellas en la fuente. (Suposición basada en el compilador de C, puede ser necesario aclarar/correcto)
También, dependiendo de la naturaleza de sus bibliotecas, objetos globales y estáticos/variables pueden ser instanciadas, causando aumento del tiempo de puesta en marcha y sobrecarga de memoria.
Ah, y el aumento de tiempo de compilación/vinculación.
Me resulta frustrante cuando edito un archivo en el árbol fuente porque algún símbolo que estoy trabajando aparece en el archivo fuente (por ejemplo, un nombre de función, donde acabo de cambiar el prototipo o, por desgracia, más típicamente, acaba de agregar el prototipo a un encabezado), así que necesito verificar que el uso sea correcto, o el compilador ahora me dice que el uso en ese archivo es incorrecto. Entonces, edito el archivo. Luego veo un problema: ¿qué está haciendo este archivo? Y resulta que aunque el código es 'usado' en el producto, realmente no se usa activamente en absoluto.
Encontré una incidencia de este problema el lunes. Un archivo con más de 10.000 líneas de código invocó una función 'extern void add_remainder (void);' con un argumento de 0. Entonces, fui a arreglarlo. Luego miré el resto del código ... Resultó que era un componente de desarrollo de hace unos 15 años que nunca se había eliminado. Limpiar el código de forma limpia resultó con ediciones menores en más de media docena de archivos, y aún no he resuelto si es seguro eliminar la constante de enumeración de la enumeración por si acaso. Temporalmente, que está marcado como 'Sin usar/Obsoleto, ¿se puede eliminar de forma segura?'.
Ese trozo de código ha tenido cobertura de ensenada cero durante los últimos 15 años - producción, prueba, ... Verdaderamente, es solo una pequeña parte de un vasto sistema - en porcentaje, es menos de un 1% de destello en el gráfico. Aún así, es un código extra desperdiciado.
desconcertante. Molesto. Es terriblemente común (he registrado y solucionado al menos media docena de errores similares hasta el momento).
Y una pérdida de mi tiempo, y el tiempo de otros desarrolladores. El archivo había sido editado periódicamente a lo largo de los años por otras personas que hacían lo que yo hacía: un trabajo completo.
+1. En resumen: "Más código => más mantenimiento." Y en mi experiencia, el tiempo de mantenimiento crece más que linealmente con el tamaño de la base de código. –
Estoy de acuerdo con ese análisis. Eso hace que el software en el que trabajo y cosas como MS Windows, ¡extremadamente difíciles de mantener! –
Incluso podría no compilarse si el árbol de compilación no está bien mantenido. si está compilando en sistemas integrados sin espacio de intercambio. El compilador puede quedarse sin memoria al intentar compilar un archivo de objeto masivo.
Nos sucedió en el trabajo recientemente.
¿Realmente aumenta el tamaño binario? Para una biblioteca enlazada dinámicamente, no creo que lo haría. – Alex
no lo haría, la contaminación del espacio de nombres es un infierno, aunque – MahdeTo
¿Qué tal con la vinculación estática? – Alex