J'ai une question assez fondamentale.
3 Réponses :
Il y a presque pas de surcharge pour avoir une DLL séparée. Fondamentalement, le premier appel à une fonction exportée d'une DLL exécutera un petit talon qui fixe les adresses de fonction afin que les appels ultérieurs soient effectués via un seul saut à travers une table de saut. La façon dont les processeurs fonctionnent, cette indirection supplémentaire est pratiquement gratuite.
Le "frais de tête" principale est en fait un coût d'opportunité, pas un "frais généreux" en soi. C'est-à-dire que les compilateurs modernes peuvent faire quelque chose appelé «Optimisation de l'ensemble du programme» dans lequel tout le module (.exe ou .dll) est compilé et optimisé à la fois, au moment de la liaison. Cela signifie que le compilateur peut faire des choses comme ajuster les conventions d'appel, les fonctions en ligne, puis sur tous les fichiers .CPP dans l'ensemble du programme, plutôt que simplement dans un seul fichier. CPPP.
Cela peut entraîner une stimulation de performances assez agréable, pour certains types d'applications. Mais bien sûr, l'optimisation de l'ensemble du programme ne peut pas se produire sur les limites de la DLL.
Pas tout à fait vrai, dans le cas habituel, les adresses de fonction sont fixées lorsque le programme est chargé, pas au moment de l'exécution. Le commentaire à propos de l'optimisation de l'ensemble du programme est mort, mais je n'ai vu aucune information sur la manière dont cela est utile.
@ Bark: Oui, je pense peut-être à des dlls chargés de retard ... dans tous les cas, la surcharge réelle elle-même est petite dans les deux cas ...
Les fonctions importées n'ont pas plus de frais généraux que les fonctions virtuelles.
Il y a deux frais généraux à une DLL. Tout d'abord, la DLL est chargée en mémoire, les adresses internes doivent être fixées pour l'adresse réelle que la DLL est chargée à, par rapport aux adresses supposées par la liaison. Cela peut être minimisé en re-basant les DLL. La deuxième surcharge est lorsque le programme et la DLL sont chargés, car le programme appelle dans la DLL aura les adresses des fonctions remplies. Ces frais généraux sont généralement négligeables, sauf pour de très grands programmes et DLL.
S'il s'agit d'une préoccupation réelle, vous pouvez utiliser des dlls chargés de retard qui ne sont que chargés qu'ils sont appelés. Si la DLL n'est jamais utilisée, il implémente par exemple une fonction très rare, elle ne sera jamais chargée du tout. L'inconvénient est qu'il y a un délai court la première fois que la DLL est appelée.
J'aime utiliser des bibliothèques liées statiquement liées, sans réduire les frais généraux, mais pour minimiser les tracas d'avoir à conserver la DLL avec le programme.