1) est basé sur le fait que l'appel d'une fonction DLL utilise toujours un saut indirect supplémentaire. Aujourd'hui, cela est généralement négligeable. À l'intérieur de la DLL, il y a un peu plus de surcharge sur les processeurs i386, car ils ne peuvent pas générer de code indépendant de la position. Sur amd64, les sauts peuvent être relatifs au compteur de programme, c'est donc une énorme amélioration.
2) C'est correct. Avec des optimisations guidées par le profilage, vous pouvez généralement gagner environ 10 à 15% de performances. Maintenant que la vitesse du processeur a atteint ses limites, cela pourrait valoir la peine.
J'ajouterais: (3) l'éditeur de liens peut organiser les fonctions dans un regroupement plus efficace du cache, de sorte que les échecs de niveau de cache coûteux soient minimisés. Cela pourrait également affecter le temps de démarrage des applications (sur la base des résultats que j'ai vus avec le compilateur Sun C ++)
Et n'oubliez pas qu'avec les DLL, aucune élimination de code mort ne peut être effectuée. Selon la langue, le code DLL peut ne pas être optimal non plus. Les fonctions virtuelles sont toujours virtuelles car le compilateur ne sait pas si un client les écrase.
Pour ces raisons, au cas où il n'y aurait pas vraiment besoin de DLL, utilisez simplement la compilation statique.
EDIT (pour répondre au commentaire, par le soulignement de l'utilisateur)
Voici une bonne ressource sur le problème de code indépendant de la position http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/
Comme expliqué, x86 ne les a pas AFAIK pour autre chose que les plages de sauts de 15 bits et non pour les sauts et appels inconditionnels. C'est pourquoi les fonctions (des générateurs) ayant plus de 32 Ko ont toujours été un problème et nécessitaient des trampolines intégrés.
Mais sur les systèmes d'exploitation x86 populaires comme Linux, vous n'avez pas besoin de vous soucier si le fichier .so / DLL n'est pas généré avec le gcc
commutateur -fpic
(ce qui impose l'utilisation des tables de saut indirectes). Parce que si vous ne le faites pas, le code est juste corrigé comme un éditeur de liens normal le déplacerait. Mais en faisant cela, il rend le segment de code non partageable et il aurait besoin d'un mappage complet du code du disque dans la mémoire et de le toucher avant qu'il puisse être utilisé (vider la plupart des caches, frapper les TLB), etc. Il y avait un temps quand cela a été considéré comme lent.
Vous n'auriez donc plus aucun avantage.
Je ne me rappelle pas ce système d' exploitation (Solaris ou FreeBSD) m'a donné des problèmes avec mon système de construction Unix parce que je ne faisais pas cela et demandé pourquoi il est écrasé jusqu'à ce que j'appliqué -fPIC
à gcc
.