Tenemos una aplicación muy modular con muchos objetos compartidos (.so). Algunas personas argumentan que en plataformas de gama baja con memoria/flash limitados, es mejor vincular estáticamente todo en un ejecutable grande ya que los objetos compartidos tienen sobrecarga.Sobrecarga de objetos compartidos
¿Cuál es su opinión al respecto?
Best Regards,
Paul
A menos que la memoria sea extremadamente apretada, el tamaño de una copia de estos archivos no es el factor determinante principal. Dado que se trata de un sistema integrado, probablemente tenga una buena idea de qué aplicaciones usarán sus bibliotecas y cuándo. Si su aplicación abre y cierra las múltiples bibliotecas a las que hace referencia diligentemente, y usted nunca tiene todas las bibliotecas abiertas simultáneamente, entonces la biblioteca compartida supondrá un ahorro significativo en la memoria RAM.
El otro factor que debe tener en cuenta es la penalización de rendimiento. Abrir una biblioteca compartida requiere una pequeña cantidad de tiempo (generalmente trivial); si tiene un procesador muy lento o requisitos de tiempo real difíciles de alcanzar, la biblioteca estática no incurrirá en la penalización de carga de la biblioteca compartida. Perfil para ver si esto es significativo o no.
En resumen, las bibliotecas compartidas pueden ser significativamente mejores que las bibliotecas estáticas en algunos casos especiales. En la mayoría de los casos, hacen poco o ningún daño. En situaciones simples, no obtiene ningún beneficio de las bibliotecas compartidas.
Por supuesto, la biblioteca compartida habrá un ahorro significativo en Flash, si usted tiene múltiples aplicaciones (o versiones de su aplicación) que utilizan la misma biblioteca. Si usa una biblioteca estática, se compilará una copia (que es aproximadamente del mismo tamaño que la biblioteca compartida [1]). Esto es útil cuando estás en una estación de trabajo de PC. Pero tú lo sabías Estás trabajando con una biblioteca que solo utiliza una aplicación.
[1] La diferencia de memoria de los archivos de la biblioteca individual es pequeña. Las bibliotecas compartidas agregan un índice y una tabla de símbolos para que dlopen(3) pueda cargar la biblioteca. Si esto es significativo o no dependerá de su caso de uso; compila para cada uno y luego compara los tamaños para determinar cuál es más pequeño en Flash. Tendrá que ejecutar y crear un perfil para determinar qué consume más RAM; deberían ser similares, excepto por la carga inicial de la biblioteca compartida.
Tener una gran cantidad de bibliotecas, por supuesto, significa más meta-datos deben ser almacenados, y también algunos de que los meta-datos (sección de la biblioteca cabeceras etc.) tendrá que ser almacenado en la RAM cuando está cargado. Pero la diferencia debería ser bastante insignificante, incluso en sistemas integrados (moderadamente modernos).
Le sugiero que pruebe ambas alternativas y mida el espacio utilizado tanto en FLASH como en RAM, y luego decida cuál es el mejor.
Los costos de las bibliotecas compartidas son más o menos (por biblioteca):
mmap y mprotect syscalls, y al menos un error de página en el tiempo de carga.Plus costos código de posición independiente:
Si tiene una aplicación grande de larga ejecución, los costos pueden no importarle en absoluto, a menos que se encuentre en un pequeño sistema integrado. Por otro lado, si está escribiendo algo que se puede invocar muchas veces para tareas cortas (como un intérprete de idiomas), estos costos pueden ser enormes. Poner todos los módulos estándar en sus propios archivos .so en lugar de enlazarlos estáticos por defecto es una gran parte de por qué Perl, Python, etc. tardan tanto en iniciarse.
Personalmente, me gustaría ir con la estrategia de utilizar módulos cargados dinámicos como herramienta extensibilidad, no como un modelo de desarrollo .