¿El uso de bibliotecas grandes hace que el código sea inherentemente más lento?

No puedo comentar sobre GLib, pero tenga en cuenta que gran parte del código en Boost es solo de encabezado y dado el principio de C++ de que el usuario solo paga por lo que está usando, las bibliotecas son bastante eficientes. Hay varias bibliotecas que requieren que se vincule con ellas (regex, sistema de archivos, etc. vienen a la mente), pero son bibliotecas separadas. Con Boost no se enlaza contra una gran biblioteca monolítica, sino solo contra los componentes más pequeños que utiliza.

Por supuesto, el otro la pregunta es - ¿cuál es la alternativa? ¿Desea implementar la funcionalidad que está en Boost usted mismo cuando lo necesite? Dado que muchas personas muy competentes han trabajado en este código y se han asegurado de que funcione a través de una multitud de compiladores y aún así sea eficiente, esto podría no ser exactamente una tarea simple. Además, estás reinventando la rueda, al menos hasta cierto punto. En mi humilde opinión puede pasar este tiempo de manera más productiva.

Boost no es una gran biblioteca.

Es una colección de muchas bibliotecas pequeñas. La mayoría de ellos son tan pequeños que están contenidos en un encabezado o dos. Usar boost::noncopyable no arrastra boost::regex o boost::thread al código. Son bibliotecas diferentes. Sólo se distribuyen como parte de la misma colección de la biblioteca. Pero solo pagas por los que usas.

Pero hablando en general, porque existen grandes bibliotecas, incluso si Boost no es una de ellas:

¿Hay alguna base para mi pensamiento, ¿o soy simplemente irrazonable y / o ignorante? Incluso si solo utilizo una o dos características de una biblioteca grande, al vincular a esa biblioteca, ¿voy a incurrir en gastos generales de rendimiento en tiempo de ejecución?

Sin base, más o menos . Puedes probarlo tú mismo.

Escribe un pequeño programa en C++ y compílalo. Ahora agregue una nueva función a ella, una que nunca se llama, pero está definida. Compilar el programa de nuevo. Suponiendo que las optimizaciones están habilitadas, se elimina por el enlazador porque es sin usar. Por lo tanto, el costo de incluir código adicional no utilizado es cero.

Por supuesto que hay excepciones. Si el código crea instancias de cualquier objeto global, es posible que no se eliminen (es por eso que incluir el encabezado iostream aumenta el tamaño del ejecutable), pero en general, puede incluir tantos encabezados y enlaces a tantas bibliotecas como desee, y no afectará el tamaño, el rendimiento o el uso de memoria de su programa * siempre que no use ninguno de los agregados codificar.

Otra excepción es que si se enlaza dinámicamente a un .dll o. so, toda la biblioteca debe ser distribuida, y así no puede ser despojada del código no utilizado. Pero las bibliotecas que se compilan estáticamente en su ejecutable (ya sea como bibliotecas estáticas (.lib or .a) o simplemente como los archivos de encabezado incluidos generalmente pueden ser recortados por el enlazador, eliminando los símbolos no utilizados.

La biblioteca grande, desde la perspectiva del rendimiento de code:

• ocupa más memoria, si tiene un binario de tiempo de ejecución (la mayoría de las partes de boost no requieren binarios de tiempo de ejecución, son "solo de encabezado"). Si bien el sistema operativo cargará solo las partes realmente utilizadas de la biblioteca en la memoria RAM, todavía puede cargar más de lo que necesita, porque la granularidad de lo que se carga es igual al tamaño de página (4 Kb solo en mi sistema, sin embargo).

• Tómese más tiempo para cargar por enlazador dinámico, si, de nuevo, necesita binarios de tiempo de ejecución. Cada vez que se carga el programa, dynamic linker tiene que coincidir con cada función que necesita la biblioteca externa para contener con su dirección real en memoria. Lleva algún tiempo, pero solo un poco (sin embargo, importa a una escala de carga de muchos programas, como el inicio del entorno de escritorio, pero no tiene opción allí).

  Y sí, tomará un salto adicional y un par de ajustes de puntero en tiempo de ejecución cada vez que llame a external función de una biblioteca compartida (dinámicamente vinculada)

Desde una perspectiva de rendimiento del desarrollador:

• Añade una dependencia externa . Estarás dependiendo de otra persona. Incluso si esa biblioteca es software libre, necesitará un gasto adicional para modificarla. Algunos desarrolladores de veeery programas de bajo nivel (estoy hablando de kernels de sistema operativo) odian confiar en cualquiera that esa es su ventaja profesional. De ahí las diatribas.

  Sin embargo, eso puede considerarse un beneficio. Si otras personas se acostumbran a boost, encontrarán conceptos y términos familiares en su programa y serán más eficaces para entenderlo y modificarlo.

• Las bibliotecas más grandes normalmente contienen conceptos específicos de bibliotecas que requieren tiempo para ser entendidos. Considere Qt. Contiene señales y ranuras e infraestructura relacionada con moc. En comparación con el tamaño de todo el Qt, aprenderlos toma una pequeña fracción de tiempo. Pero si utilizas un una pequeña parte de una biblioteca tan grande, eso puede ser un problema.

El exceso de código no hace mágicamente que el procesador funcione más lento. Todo lo que hace es sentarse allí ocupando un poco de memoria.

Si estás enlazando estáticamente y tu enlazador es del todo razonable, entonces solo incluirá las funciones que realmente usas de todos modos.

El término que me gusta para frameworks, conjuntos de bibliotecas y algunos tipos de herramientas de desarrollo es tecnologías de plataforma. Las tecnologías de plataforma tienen costos que van más allá del impacto en el tamaño y el rendimiento del código.

1. Si su proyecto está destinado a ser utilizado como una biblioteca o marco, puede terminar presionando las opciones de tecnología de su plataforma a los desarrolladores que usan su biblioteca.

2. Si distribuye su proyecto en forma de fuente, puede terminar empujando las opciones de tecnología de plataforma en sus usuarios finales.

3. Si no vincula estáticamente todos los frameworks y bibliotecas elegidos, puede terminar sobrecargando a sus usuarios finales con problemas de control de versiones de bibliotecas.

4. Compile la productividad del desarrollador de efectos de tiempo. Enlaces incrementales, encabezados precompilados, administración adecuada de dependencias de encabezados, etc., puede ayudar a administrar los tiempos de compilación, pero no elimina los problemas de rendimiento del compilador asociados con las cantidades masivas de código en línea algunas tecnologías de plataforma introducir.

5. Para los proyectos que se distribuyen como fuente, el tiempo de compilación afecta a los usuarios finales del proyecto.

6. Muchas tecnologías de plataforma tienen sus propios requisitos de entorno de desarrollo. Estos requisitos pueden acumularse, lo que dificulta y consume mucho tiempo para que los nuevos desarrolladores de un proyecto puedan replicar el entorno necesario para permitir la compilación y la depuración.

7. El uso de algunas tecnologías de plataforma en efecto crea una nueva lenguaje de programación para el proyecto. Esto hace que sea más difícil para los nuevos desarrolladores contribuir.

Todos los proyectos tienen dependencias de tecnología de plataforma, pero para muchos proyectos hay beneficios reales de mantener estas dependencias al mínimo.

Puede haber una pequeña sobrecarga al cargar estas bibliotecas si están enlazadas dinámicamente. Esto normalmente será una pequeña, pequeña fracción del tiempo que su programa pasa en ejecución.

Sin embargo, no habrá sobrecarga una vez que todo esté cargado.

Si no quieres usar todo de boost, entonces no lo hagas. Es modular, así que puedes usar las partes que quieras e ignorar el resto.

Más grande no implica inherentemente más lento. Contrariamente a algunas de las otras respuestas, tampoco hay una diferencia inherente entre las bibliotecas almacenadas completamente en encabezados y las bibliotecas almacenadas en archivos objeto.

Las bibliotecas de solo encabezado pueden tener una ventaja indirecta. La mayoría de las bibliotecas basadas en plantillas tienen que ser solo de encabezado (o gran parte del código termina en encabezados de todos modos), y las plantillas dan muchas oportunidades para la optimización. Tomar código en una biblioteca de archivos objeto típica y moverlo todo a encabezados no, sin embargo, generalmente tiene muchos buenos efectos (y podría conducir a la hinchazón del código).

La respuesta real para una biblioteca en particular generalmente dependerá de su estructura general. Es fácil pensar en "Boost" como algo enorme. De hecho, es una enorme colección de bibliotecas, la mayoría de las cuales son individualmente bastante pequeñas. No se puede decir mucho (de manera significativa) sobre Boost en su conjunto, porque las bibliotecas individuales están escritas por personas diferentes, con diferentes técnicas, objetivos, etc. Algunos de ellos (por ejemplo, Formato, Asignar) realmente son más lentos que casi cualquier cosa que sea muy probable que hagas por tu cuenta. Otros (por ejemplo, Pool) proporcionan cosas que usted mismo podría hacer, pero probablemente no lo hará, para obtener al menos mejoras de velocidad menores. Unos pocos (por ejemplo, uBLAS) utilizan la magia de plantilla de servicio pesado para correr más rápido de lo que cualquiera, excepto un pequeño porcentaje de nosotros puede esperar lograr por nuestra cuenta.

Hay, por supuesto, bastantes bibliotecas que realmente son individualmente grandes biblioteca. En bastantes casos, estos realmente son más lentos de lo que escribirías tú mismo. En particular, muchos (la mayoría?) de ellos intentan ser mucho más generales que casi cualquier cosa que sea probable que escribas por tu cuenta. Mientras que no necesariamenteconduce a un código más lento, definitivamente hay una fuerte tendencia en esa dirección. Al igual que con muchos otros códigos, cuando estás desarrollando bibliotecas comercialmente, los clientes tienden a estar mucho más interesados en las características que en las cosas como el tamaño de la velocidad.

Algunas bibliotecas también dedican mucho espacio, código (y a menudo al menos bits de tiempo) a resolver problemas que muy bien pueden no importarle en absoluto. Solo por ejemplo, hace años utilicé una biblioteca de procesamiento de imágenes. Su soporte para más de 200 formatos de imagen sonaba realmente impresionante (y de alguna manera lo fue), pero estoy bastante seguro de que nunca lo usé para lidiar con más de una docena de formatos (y probablemente podría haber obtenido soportando solo la mitad de esa cantidad). OTOH, incluso con todo eso todavía era bastante rápido. Soportar menos mercados podría haber restringido su mercado hasta el punto de que el código realmente habría sido más lento (solo por ejemplo, manejaba JPEG más rápido que IJG).

Como otros han dicho, hay cierta sobrecarga cuando se agrega una biblioteca dinámica. Cuando la biblioteca se carga por primera vez, se deben realizar reubicaciones, aunque esto debería ser un costo menor si la biblioteca se compila correctamente. El costo de buscar símbolos individuales también aumenta, ya que aumenta el número de bibliotecas que deben buscarse.

El costo en memoria de agregar otra biblioteca dinámica depende en gran medida de la cantidad de ella que realmente use. Una página de código no será se carga desde el disco hasta que se ejecuta algo en él. Sin embargo, se cargarán otros datos, como encabezados, tablas de símbolos y tablas hash integradas en el archivo de la biblioteca, que generalmente son proporcionales al tamaño de la biblioteca.

Hay un gran documento de Ulrich Drepper, el principal colaborador de glibc, que describe el proceso y la sobrecarga de las bibliotecas dinámicas.

Depende de cómo funciona el enlazador. Algunos enlazadores son perezosos e incluirán todo el código en la biblioteca. Los enlazadores más eficientes solo extraerán el código necesario de una biblioteca. He tenido experiencia con ambos tipos.

Las bibliotecas más pequeñas tendrán menos preocupaciones con cualquier tipo de enlazador. El peor de los casos con una biblioteca pequeña es una pequeña cantidad de código no utilizado. Muchas bibliotecas pequeñas pueden aumentar el tiempo de compilación. La compensación sería tiempo de construcción vs. espacio de código.

An interesante prueba del enlazador es el clásico Hello World programa:

#include <stdio>
#include <stdlib>
int main(void)
{
  printf("Hello World\n");
  return EXIT_SUCCESS;
}

La función printf tiene muchas dependencias debido a todo el formato que puede necesitar. Un enlazador perezoso pero rápido puede incluir una "biblioteca estándar" para resolver todos los símbolos. Una biblioteca más eficiente solo incluirá printf y sus dependencias. Esto hace que el enlazador sea más lento.

El programa anterior se puede comparar con este usando puts:

#include <stdio>
#include <stdlib>
int main(void)
{
  puts("Hello World\n");
  return EXIT_SUCCESS;
}

Generalmente, el puts la versión debe ser más pequeña que la versión printf, porque puts no necesita formato, por lo tanto, menos dependencias. Los enlazadores perezosos generarán el mismo tamaño de código que el programa printf.

En resumen, las decisiones de tamaño de biblioteca tienen más dependencias en el enlazador. Específicamente, la eficiencia del enlazador. En caso de duda, muchas bibliotecas pequeñas dependerán menos de la eficiencia del enlazador, pero harán que el proceso de compilación sea más complicado y lento.

1. Lo que hay que hacer con las preocupaciones de rendimiento, en general, no es entretenerlas, porque hacerlo es adivinar que son un problema, porque si no sabes que lo son, estás adivinando, y adivinar es el concepto central detrás de la "optimización prematura". Lo que hay que hacer con los problemas de rendimiento es, cuando los tienes, y no antes de, diagnosticarlos. Los problemas casi nunca son algo que habrías adivinado. Aquí hay un extendido ejemplo.

2. Si lo hace una buena cantidad, llegará a reconocer los enfoques de diseño que tienden a causar problemas de rendimiento, ya sea en su código o en una biblioteca. (Las bibliotecas ciertamente pueden tener problemas de rendimiento.) Cuando aprendes eso y lo aplicas a proyectos entonces en cierto sentido estás optimizando prematuramente, pero tiene el efecto deseado de todos modos, de evitar problemas. Si puedo resumir lo que probablemente aprenderás, es que demasiadas capas de la abstracción y las jerarquías de clase exageradas (especialmente las llenas de actualizaciones de estilo de notificación) son las razones que a menudo causan problemas de rendimiento.

Al mismo tiempo, comparto su circunspección sobre las bibliotecas de terceros y demás. Demasiadas veces he trabajado en proyectos donde algún paquete de 3rd-party fue "apalancado" para "sinergia", y luego el proveedor se esfumó o abandonó el producto o lo dejó obsoleto porque Microsoft cambió las cosas en operativo. Entonces nuestro producto que se apoyó fuertemente en el paquete de 3rd-party comienza a no funcionar, lo que requiere un gran gasto de nuestra parte, mientras que los programadores originales se han ido hace mucho tiempo.

"otra bola y cadena". ¿En serio?

¿O es una plataforma estable y confiable que habilita su aplicación en primer lugar?

Considere que a algunas personas les puede gustar un "demasiado grande y ... biblioteca "hinchada" porque la usan para otros proyectos y realmente confían en ella.

De hecho, pueden negarse a meterse con su software específicamente porque evitó el uso de la obvia "demasiado grande y ... biblioteca hinchada".

Técnicamente, la respuesta es que sí, lo hacen. Sin embargo, estas ineficiencias son muy rara vez prácticamente importantes. Voy a asumir un lenguaje estáticamente compilado como C, C++, o D aquí.

Cuando un ejecutable se carga en la memoria en un sistema operativo moderno, el espacio de direcciones simplemente se asigna a él. Esto significa que, no importa cuán grande sea el ejecutable, si hay bloques de código de tamaño de página completos que no se utilizan, nunca tocarán la memoria física. Vosotros habréis desperdiciado el espacio, sin embargo, y ocasionalmente esto puede importar un poco en sistemas de 32 bits.

Cuando se enlaza a una biblioteca, un buen enlazador generalmente desechará el exceso de cosas que no se usan, aunque especialmente en el caso de las instanciaciones de plantillas esto no siempre sucede. Por lo tanto, sus binarios pueden ser un poco más grandes de lo estrictamente necesario.

Si tiene código que no utiliza en gran medida intercalado con el código que utiliza, puede terminar perdiendo espacio en la caché de la CPU. Sin embargo, como las líneas de caché son pequeñas (generalmente 64 bytes), esto rara vez sucederá en una medida prácticamente importante.

Pregúntate cuál es tu objetivo. Es una estación de trabajo de gama media de hoy-no hay problema. Es hardware más antiguo o incluso un sistema embebido limitado, entonces podría ser.

Como han dicho los posters anteriores, solo tener el código allí no te cuesta mucho en rendimiento (podría reducir la localidad de las cachés y aumentar los tiempos de carga).

Fwiw, trabajo en Microsoft Windows y cuando construimos Windows; build compiled for SIZE son más rápidos que builds compiled for SPEED porque recibes menos visitas de error de página.

FFTW y ATLAS son dos bibliotecas bastante grandes. Curiosamente, juegan un papel importante en el software más rápido del mundo, aplicaciones optimizadas para ejecutarse en supercomputadoras. No, el uso de bibliotecas grandes no hace que su código sea lento, especialmente cuando la alternativa es implementar rutinas FFT o BLAS por sí mismo.

Tienes razón al estar preocupado, especialmente cuando se trata de boost. No se debe tanto a que cualquiera que las escriba sea incompetente, sino a dos problemas.

1. Las plantillas son solo código inherentemente hinchado. Esto no importaba tanto hace 10 años, pero hoy en día la CPU es mucho más rápida que el acceso a la memoria y esta tendencia continúa. Casi diría que las plantillas son una característica obsoleta.

No es tan malo para el código de usuario que suele ser algo práctico, pero en muchos bibliotecas todo se define en términos de otras plantillas o plantilla en varios elementos (es decir, explosiones exponenciales de código de plantilla).

Simplemente añadiendo en iostream añade unos 3 mb (!!!) a su código. Ahora agregue algunas tonterías de impulso y tendrá 30 mb de código si declara sinply un par de estructuras de datos particularmente extrañas.

Peor, ni siquiera puedes perfilar fácilmente esto. Puedo decirte que la diferencia entre el código escrito por mí y el código de las bibliotecas de plantillas es DRAMÁTICA pero para un enfoque más ingenuo, puede pensar que lo está haciendo peor desde una simple prueba, pero el costo en código hinchado tomará su herramienta en una gran aplicación realworld.

1. Complejidad. Cuando nos fijamos en las cosas en Boost, son todas las cosas que complican su código en gran medida. Cosas como punteros inteligentes, funtores, todo tipo de cosas complicadas. Ahora, no diré que nunca es una buena idea usar estas cosas, pero casi todo tiene un gran costo de algún tipo. Especialmente si no entiende exactamente, quiero decir exactamente, lo que está haciendo.

Pero la gente se entusiasma y finge que tiene algo que ver con el 'diseño' para que la gente tenga la impresión de que es la forma en que debe hacer todo, no solo algunas herramientas extremadamente especializadas que deberían usarse rara vez. Si alguna vez.