Frais généraux de la DLL

Question

J'ai une question assez basique.

1. Lorsqu'une bibliothèque est utilisée uniquement par un seul processus. Devrais-je le garder comme une bibliothèque statique?
2. Si j'utilise la bibliothèque en tant que DLL, mais qu'un seul processus l'utilise. ** Quel sera les frais généraux? *

Answer 1

Il est presque pas de frais généraux d'avoir une DLL séparée. Fondamentalement, le premier appel à une fonction exportée à partir d'une DLL exécutera un petit bout qui fixe les adresses de fonction de sorte que les appels ultérieurs sont effectués via un seul saut à travers une table de saut. Le fonctionnement des processeurs, cette indirection supplémentaire est pratiquement gratuite.

Le "surcoût" principal est en fait un coût d'opportunité, pas un "surcoût" en soi. C'est-à-dire que les compilateurs modernes peuvent faire quelque chose appelé «optimisation de programme complet» dans laquelle le module entier (.exe ou .dll) est compilé et optimisé en même temps, au moment de la liaison. Cela signifie que le compilateur peut faire des choses comme ajuster les conventions d'appel, les fonctions inline et ainsi de suite à travers tous les fichiers .cpp dans le programme entier, plutôt que juste dans un seul fichier .cpp.

Cela peut entraîner une augmentation des performances assez agréable, pour certains types d'applications. Mais bien sûr, l'optimisation du programme entier ne peut pas se produire à travers les limites de la DLL.

Answer 2

Les fonctions importées n'ont pas plus de surcharge que les fonctions virtuelles.

Answer 3

Il y a deux surdébits dans une DLL. Tout d'abord, lorsque la DLL est chargée en mémoire, les adresses internes doivent être corrigées pour l'adresse réelle à laquelle la DLL est chargée, contrairement aux adresses prises en charge par l'éditeur de liens. Cela peut être minimisé en re-basant les DLL. Le deuxième surcoût est lorsque le programme et DLL sont chargés, comme les appels de programme dans la DLL ont les adresses des fonctions remplies. Ces frais généraux sont généralement négligeables, sauf pour les très grands programmes et DLL.

Si cela vous préoccupe, vous pouvez utiliser des DLL chargées en différé qui ne sont chargées que lorsqu'elles sont appelées. Si la DLL n'est jamais utilisée, par exemple, elle implémente une fonction très rare, alors elle ne sera jamais chargée du tout. L'inconvénient est qu'il y a un court délai la première fois que la DLL est appelée. J'aime utiliser des bibliothèques liées statiquement, pas pour réduire la surcharge mais pour minimiser les tracas d'avoir à conserver la DLL avec le programme.