Hice una biblioteca GUI para juegos. Mi demostración de prueba se ejecuta a 60 fps. Cuando ejecuto esta demostración con la versión estática de mi biblioteca, toma 2-3% de CPU en taskmanager. Cuando uso la versión DLL, usa alrededor del 13-15%. ¿Eso es normal? Es así, ¿cómo podría optimizarlo? Ya le pido que use/O2 para la mayoría de las funciones en línea.¿Es un DLL más lento que un enlace estático?
No inicie su temporizador de rendimiento hasta que la DLL haya tenido la oportunidad de ejecutar su funcionalidad una vez. Esto le da tiempo de cargar en la memoria. Luego, inicie el temporizador y verifique el rendimiento. Básicamente, debería coincidir con la de la lib estática.
También tenga en cuenta que la ubicación de carga de la DLL puede afectar en gran medida la rapidez con que se carga. La dirección base predeterminada para las DLL es 0x400000. Si ya tiene otra DLL en esa ubicación, entonces el proceso de carga debe realizar un costoso paso de redireccionamiento que retrasará aún más el tiempo.
Si tiene un conflicto así, simplemente elija una dirección base diferente en Visual Studio.
+1 por mencionar problemas con la dirección base. –
El problema de la dirección base solo sería un problema en el tiempo de carga. –
Tendrá la sobrecarga de cargar la DLL (debería ser solo una vez al principio). No está enlazado estáticamente con llamadas directas, por lo que esperaría una pequeña cantidad de gastos generales, pero no mucho.
Sin embargo, algunos archivos DLL tendrán gastos generales mucho más altos. Estoy pensando en los objetos COM, aunque puede haber otros ejemplos. COM agrega mucha sobrecarga en llamadas a funciones entre objetos.
No está claro qué está vinculado estático/dinámicamente. ¿Está el DLL de tu librería enlazado estáticamente con sus dependencias? ¿Es posible que la DLL llame a otras DLL (que será lenta)? Tal vez intente ejecutar un generador de perfiles de valgrind en su ejecutable para determinar de dónde viene todo el uso de la CPU.
Si llama a las funciones DLL, no pueden ser inline para la persona que llama. Deberías pensar un poco sobre tus límites de DLL.
Puede ser que sea mejor para su aplicación tener un pequeño ejecutable bootstrap que simplemente ejecuta un bucle principal en su DLL. De esta manera puede evitar mucha sobrecarga para las llamadas a funciones.
¿Olvidó su contraseña? –
Debe hacer un perfil y ver dónde está la diferencia significativa. –
No hay motivo para perfil. Las conjeturas no informadas deberían ser suficientes para determinar dónde podría haber cuellos de botella en su aplicación. Diablos, ni siquiera necesitas mirar el código fuente. –