tipos sb2 lista linea ejemplos ejecutables convertir consola comandos archivos performance dll linker static-linking dynamic-linking

performance - lista - convertir sb2 a exe



¿Es un ejecutable vinculado estáticamente más rápido que un ejecutable vinculado dinámicamente? (2)

Dado que las bibliotecas vinculadas dinámicamente tienen que resolverse en tiempo de ejecución, ¿son los ejecutables vinculados estáticamente más rápido que los ejecutables vinculados dinámicamente?


Depende del estado de su disco y de si las DLL se pueden usar en otros procesos. Un inicio en frío ocurre cuando su programa y sus DLL nunca se cargaron antes. Un EXE sin DLL tiene un inicio en frío más rápido ya que solo se necesita encontrar un archivo. Tendría que tener un disco mal fragmentado que esté casi lleno para no tener este caso.

Una DLL puede comenzar a pagar cuando ya está cargada en otro proceso. Ahora las páginas de códigos de la DLL son simplemente compartidas, la sobrecarga de inicio es muy baja y el uso de memoria es eficiente.

Un caso similar es un inicio cálido, un inicio en el que la DLL todavía está disponible en la memoria caché del sistema de archivos desde la última vez que se usó. La diferencia entre un arranque en frío y un arranque en caliente puede ser bastante significativa en un disco lento. La única razón por la que a todo el mundo le gusta un SSD.


La vinculación estática produce un archivo ejecutable más grande que la vinculación dinámica porque tiene que compilar todo el código de la biblioteca directamente en el ejecutable. El beneficio es una reducción en la sobrecarga por no tener que llamar a funciones desde una biblioteca, y en cualquier lugar desde tiempos de carga algo más rápidos.

Un ejecutable enlazado dinámicamente será más pequeño porque realiza llamadas en tiempo de ejecución a bibliotecas de código compartidas. Hay varios beneficios para esto, pero los más importantes desde la perspectiva de la velocidad o la optimización son la reducción de la cantidad de espacio en disco y la memoria consumida, y la mejora de la multitarea debido a la reducción del consumo total de recursos (especialmente en Windows).

Así que es una compensación: hay argumentos por los cuales uno de los dos podría ser ligeramente más rápido. Dependería de muchas cosas diferentes, por ejemplo, en qué medida las rutinas de velocidad crítica en el programa se basan en las llamadas a las funciones de la biblioteca. Pero el punto importante a destacar en la declaración anterior es que podría ser un poco más rápido. La diferencia de velocidad será casi imperceptible y difícil de distinguir incluso de las fluctuaciones normales y esperadas.

Si realmente te importa, haz un benchmark y verás. Pero le aconsejo que esto sea una pérdida de tiempo y que existen formas más efectivas y más importantes para aumentar la velocidad de su aplicación. Estarás mucho mejor a largo plazo considerando otros factores distintos a la velocidad al tomar la decisión de "vincular dinámicamente o vincular estáticamente". Por ejemplo, puede valer la pena considerar la vinculación estática si necesita hacer que su aplicación sea más fácil de implementar, particularmente en diversos entornos de usuarios. O, la vinculación dinámica puede ser una mejor opción (especialmente si esas bibliotecas compartidas no son las suyas) porque su aplicación cosechará automáticamente los beneficios de las actualizaciones realizadas a cualquiera de las bibliotecas compartidas a las que llama sin tener que mover un dedo.

EDIT: Microsoft hace la recomendación específica de que prefiera el enlace dinámico sobre el enlace estático :

No se recomienda redistribuir las aplicaciones de C / C ++ que se vinculan estáticamente a las bibliotecas de Visual C ++. A menudo se asume erróneamente que al vincular estáticamente su programa a las bibliotecas de Visual C ++ es posible mejorar significativamente el rendimiento de una aplicación. Sin embargo, el impacto en el rendimiento de la carga dinámica de bibliotecas de Visual C ++ es insignificante en casi todos los casos. Además, el enlace estático no permite el servicio de la aplicación y sus bibliotecas dependientes por el autor de la aplicación o por Microsoft. Por ejemplo, considere una aplicación que está estáticamente vinculada a una biblioteca en particular, que se ejecuta en una computadora cliente con una nueva versión de esta biblioteca. La aplicación aún utiliza el código de la versión anterior de esta biblioteca y no se beneficia de las mejoras de la biblioteca, como las mejoras de seguridad. Se recomienda encarecidamente a los autores de las aplicaciones C / C ++ que analicen el escenario de servicio antes de decidir vincular estáticamente a las bibliotecas dependientes, y utilizar el enlace dinámico siempre que sea posible.