Discussion :

[a_lincoln54]

Bonjour à tous,

Développant une application assez lourde qui mélange à la fois de la gestion de fichier (lecture / écriture sur fichier txt) et beucoup de maths, je voudrais savoir si il y a un intérêt à "fragmenter le programme en DLL".
Je sais - d'après un précédent message posté sur ce forum - que les DLL permettent une meilleure révision / mise à jour du code mais qu'elles sont "lentes" à utiliser... Est-ce que cela optimise la gestion de la mémoire lorsque le programme est exécuté ? Y a t'il plus de risque de plantage / viol. accès ? Bref quels en sont les avantages par rapport à un gros exe.

Je vous remercie par avance pour votre réponse.

[poukill]

Je vais peut-être dire une bêtise, mais je crois que l'intérêt principal est d'être partageable entre plusieurs programmes. Plusieurs .exe comme tu dis peuvent accéder à la même DLL au lieu de chacun copier en static dans l'exécutable.

[ram-0000]

Une DLL permet effectivement de séparer de manière logique le code. Cela n'empêche pas un crash dans une DLL de remonter à l'appli qui utilise cette DLL. une DLL ne crashe jamais, c'est l'appli qui utilise cette DLL qui crash.

Une DLL permet effectivement de partager du code entre plusieurs applications. Changer/modifier cette DLL suite à un bug corrige ce bug dans toutes les applis qui utilisent cette DLL. Pas besoin de relinker.

Autre avantage, le code n'est pas dupliqué donc il y a économie de place sur le disque. Ceci est peut être un peu moins vrai de nos jours car le GOctet ne vaut plus rien mais il y a 20 ans (Ah!! souvenirs, souvenirs ), cela valait le coup.

Inconvénient (ou désavantages) de la DLL, j'en voie au moins 2 :
D'abors le temps de chargement du programme, il sera effectivement plus long mais cela est négligeable avec la puissance CPU dont on dispose maintenant donc cet inconvénient est vraiment très petit (voire même inexistant).

Autre inconvénient, lors de la mise à jour de la DLL, il faut s'assurer qu'aucun programme ne l'utilise plus afin de pouvoir la remplacer (sinon, pas possible). Et cela est un problème pour les services qui font des mises à jour de code par Internet. Il faut bien gérer les dépendances et les locks.

Donc en final les DLL oui sauf dans certains cas très précis et très rares.

[a_lincoln54]

Merci pour vos réponses respectives. Par rapport à ce que disait ram_0000, si j'ai bien compris les paragraphes " :

1- "Une DLL permet effectivement de partager du code entre plusieurs applications. Changer/modifier cette DLL suite à un bug corrige ce bug dans toutes les applis qui utilisent cette DLL. Pas besoin de relinker."

2- "Autre avantage, le code n'est pas dupliqué donc il y a économie de place sur le disque. Ceci est peut être un peu moins vrai de nos jours car le GOctet ne vaut plus rien mais il y a 20 ans (Ah!! souvenirs, souvenirs ), cela valait le coup."

Si l'on réalise une fonction, utilisée dans plusieurs programmes, mais dont le code se trouve dans un fichier unique (par ex. fonction.h) cela est-il bien équivalent à l'avantage du §2 de la citation ?? Par contre, il est absolument nécessaire de recompiler le tout dans ce cas, donc on perd l'avantage du §1, est ce que je me trompe ??

merci d'avance.

[Mat.M]

Inconvénient (ou désavantages) de la DLL, j'en voie au moins 2 :
D'abors le temps de chargement du programme, il sera effectivement plus long

le temps de chargement d'une dll n'est ni plus ni moins long ; c'est un programme exécutable au même titre qu'un .exe.
Je ne sais pas qui a décrêté que les dll étaient longues à charger..
Pour le projet de jeu que je fais je mets toutes les bitmaps dans une dll qui est chargée pour une partie donnée; la dll fait plus de 8Mo et le temps de chargement est très faible

[bolhrak]

Si l'on réalise une fonction, utilisée dans plusieurs programmes, mais dont le code se trouve dans un fichier unique (par ex. fonction.h) cela est-il bien équivalent à l'avantage du §2 de la citation ?? Par contre, il est absolument nécessaire de recompiler le tout dans ce cas, donc on perd l'avantage du §1, est ce que je me trompe ??

merci d'avance.

Le relink est nécessaire seulement dans le cas où tu modifies l'interface fournies aux clients (autrement dit les headers inclus par les programmes utilisant cette DLL). S'il s'agit juste d'une modification de l'implémentation (.cpp + .h non fournis au client), aucun besoin de relink.

[zais_ethael]

Pour le projet de jeu que je fais je mets toutes les bitmaps dans une dll qui est chargée pour une partie donnée; la dll fait plus de 8Mo et le temps de chargement est très faible

Comme tous les monde, j'ai eu quelque cours sur le sujet (assez superficiels). Dans le cas dont je me souviens le mieux, il fallait procéder à un réadressage en modifiant toutes les instructions jump et certaines load/store au chargement d'une dll, ce qui la rendait toujours un peu plus longue qu'un exe à charger.
Je ne sais plus si les systèmes d'exploitations fonctionnent effectivement comme ça mais je ne pense pas qu'il existe une autre façon de procéder qui soit vraiment parfaite et dénuée d'opérations lourdes comme celle ci.

Dans ton cas ça ne compte pas, si tu n'as que des données binaires dans ta dll il n'y a effectivement rien à modifier, mais d'un autre coté tu pourrais aussi bien te passer de dll .

[ram-0000]

le temps de chargement d'une dll n'est ni plus ni moins long ; c'est un programme exécutable au même titre qu'un .exe.
Je ne sais pas qui a décrêté que les dll étaient longues à charger..
Pour le projet de jeu que je fais je mets toutes les bitmaps dans une dll qui est chargée pour une partie donnée; la dll fait plus de 8Mo et le temps de chargement est très faible

Si si, j'insiste, le chargement d'une DLL de fonctions est nécessairement plus long car il faut que le loader gère la relocation des adresses des fonctions. Par contre, je suis bien d'accord, ce temps de chargement bien que plus long est insignifiant maintenant.

Dans tons cas, cette DLL pourrait s'apparenter plus à une DLL de ressources qu'une DLL de code donc le temps de chargement n'a aucune influence dessus.

[nicroman]

C'est pas tout à fait vrai... ni tout à fait faux....

D'abord un interêt oublié dans les posts précédents: Le chargement dynamique de code. Pour des fonctions "on-demand" par exemple: un logiciel de dessin n'aurait que le minimum chargé en mémoire au démarrage... l'utilsation d'un outil irait charger une DLL additionel. Ou bien sur, les plug-ins.

Le chargement d'un EXE (ou DLL c'est la même chose), se fait par simple memory mapping de la zone du disque... Si le disque est correctement défragmenté, le chargement se fait donc pratiquement à la vitesse nominale du disque (150Mbps pour un SATA donc... ca fait quand même 20Mops !). Et même mieux... le sharing est effectif pour la partie code entre plusieurs processus (le chargement de winnt.dll est donc pratiquement instantanné par exemple) !!!!


La DLL contient une table de correspondances entre fonction "toto" (décorée) et l'addresse ou celle-ci se situe dans la DLL.
C'est donc l'executable qui va devoir modifier ses jumps (et non la DLL) (en additionant au passage l'addresse de base de la DLL en mémoire).

Bien évidemment, si on charge une DLL à la main (LoadLibrary), par exemple pour des plug-ins (ou des fonctions "on-demand"), cette étape n'a pas lieu.

Bien entendu, l'executable ne va pas chercher tous les jumps dans son code pour "re-linker", mais fait une indirection vers une table de link. Ce qui veut dire que la quantité de travail a effectuer au chargement est proportionel au nombre de fonctions utilisées par l'exécutable (et non à la taille de la DLL).

A noter pour finir que cette indirection induit un surcout sur les appels de fonctions non-virtuelles. Mais comme déjà évoqué maintes fois, ce surcôut est parfaitement négligeable.