J'ai fait une bibliothèque GUI pour les jeux. Ma démonstration de test fonctionne à 60 fps. Lorsque j'exécute cette démo avec la version statique de ma bibliothèque, il faut 2-3% de cpu dans taskmanager. Quand j'utilise la version DLL, elle utilise environ 13-15%. Est-ce normal? Est-ce le cas, comment pourrais-je l'optimiser? Je lui demande déjà d'utiliser/O2 pour la plupart des fonctions inlining.Une DLL est-elle plus lente qu'un lien statique?
Ne démarrez pas votre temporisateur de performances tant que la DLL n'a pas eu l'occasion d'exécuter sa fonctionnalité une seule fois. Cela lui donne le temps de charger dans la mémoire. Ensuite, démarrez la minuterie et vérifiez les performances. Il devrait alors correspondre à celui de la lib statique.
Gardez également à l'esprit que l'emplacement de chargement de la DLL peut grandement affecter la vitesse de chargement. L'adresse de base par défaut pour les DLL est 0x400000. Si vous avez déjà une autre DLL à cet endroit, le processus de chargement doit effectuer une étape de ré-adressage coûteuse qui va encore plus loin.
Si vous avez un tel conflit, choisissez simplement une autre adresse de base dans Visual Studio.
+1 pour avoir mentionné les problèmes d'adresse de base. –
Le problème d'adresse de base ne serait qu'un problème au moment du chargement. –
Vous aurez le temps de chargement de la DLL (devrait être juste une fois au début). Il n'est pas lié statiquement aux appels directs, donc je m'attendrais à une petite quantité de frais généraux mais pas beaucoup.
Toutefois, certaines DLL auront des frais généraux beaucoup plus élevés. Je pense aux objets COM bien qu'il puisse y avoir d'autres exemples. COM ajoute beaucoup de surcharge sur les appels de fonction entre les objets.
Il est un peu difficile de savoir ce qui est lié statiquement/dynamiquement. La DLL de votre bibliothèque est-elle liée statiquement à ses dépendances? Est-il possible que la DLL appelle d'autres DLL (qui sera lent)? Peut-être essayer d'exécuter un profileur à partir de valgrind sur votre exécutable pour déterminer d'où vient toute l'utilisation du processeur.
Si vous appelez des fonctions DLL, elles ne peuvent pas être intégrées pour un appelant. Vous devriez réfléchir un peu à vos limites de DLL.
Il est peut-être préférable que votre application dispose d'un petit fichier bootstrap exe qui exécute simplement une boucle principale dans votre DLL. De cette façon, vous pouvez éviter beaucoup de frais généraux pour les appels de fonction.
Avez-vous profilé votre application? –
Vous devez profiler et voir où se trouve la différence significative. –
Aucune raison de profiler. Les devinettes non renseignées devraient être suffisantes pour déterminer les éventuels goulots d'étranglement dans votre application. Enfer, n'a même pas vraiment besoin de regarder le code source. –