La taille des programmes Delphi

Sur l'excellent forum de discussion francophone nzn.fr.delphi, une question revient régulièrement : "comment réduire la taille des exe".

Alors, que remarque-t-on sur la taille d'un executable Delphi :
  1. Un executable compilé avec Delphi version n+1 est plus gros qu'avec la version n
  2. Un executable qui utilise la VCL est plus gros qu'un programme qui utilise directement les API Windows
  3. Un executable qui utilise les paquets d'execution (Delphi 3+) perd du poids de façon radicale
  4. Un projet tout bête (un TForm et un TButton) pèse lourd pour pas grand chose

La différence d'une version à l'autre :

Delphi est un compilateur optimisé, il inclut uniquement dans l'executable final le code utilisé. Donc tout code dit "mort" (c'est à dire jamais utilisé par le programme) est ignoré à la compilation...on le remarque dans l'IDE par les pastilles de couleur dans la marge de l'éditeur, seules les lignes qui produisent du code en affiche une.


Mais Delphi ne peut pas tout optimiser, et Borland à fait des choix entre simplicité d'utilisation et optimisation au quart de bit. Donc plus Delphi supporte de fonctionnalités (DDE, OLE, COM, DCOM, ActiveX, SOAP...) plus l'unité SYSTEM grossie; cette unité est le coeur de Delphi, toutes les fonctionnalités de bases y sont codées. Donc une version de Delphi "plus récente" possède un noyau légèrement plus gros que la version précédente.

A cela s'ajoute une VCL toujours plus riche qui propose de s'interfacer avec les dernières technologies Windows, et là encore l'unité CLASSES, base de la VCL , grossie d'une version à l'autre.

Mais tout cela n'est pas dramatique, ce que l'on perd sur une taille minimale on le gagne sur l'ensemble du projet. En effet, le projet ne grossi pas proportionnellement à la quantité de code, une fois le premier palier passé (la taille minimale) le projet prend du poids, petit à petit. Si les dernières versions de Delphi partent avec un handicap, il est rattrapé par un meilleur compilateur et des objets aux fonctionnalités plus riches que les versions précédentes.

L'utilisation directe des API :

C'est tout à fait vrai, si vous programmez une application entièrement à la main avec les API Windows, l'executable sera plus petit (pour la raison évoquée juste au dessus). C'est à vous de voir, personnellement je préfère cliquer dans l'EDI pour dessiner mon application que de taper le code à la main :)

Par contre, pour des applications serveur ou des procédures batch, vous avez tout intéret (à mon avis) de passer par des applications console...

Les paquets d'execution :

L'executable est tout petit, mais il n'est plus autonome, il utilise alors ces fameux paquets d'execution...c'est une solution intéressante dans le cas ou vous utilisez plusieurs applications Delphi qui pourront partager ce code; dans le cas d'une application isolée, je ne le recommande pas.

Les petits projets de plus en plus lourd !

Oui, c'est vrai, pour les petits projets la VCL pèse parfois lourd (au moins dans l'esprit du développeur)...mais il est possible de contourner le problème avec des solutions comme ma VCL light...mais c'est vraiment pour de tout petits projets :)

Les Solutions

  • Les compacteurs d'exe: comme UPX,le gain est visible, l'exe est plus petit.
    Mais cette solution est loin d'être parfaite ! Il faut savoir que sous Windows l'executable n'est pas chargé complètement en mémoire, il est chargé au fur et à mesure en fonction des besoins...les compacteurs placent tout le projet dans une ressource qui est entièrement chargée en mémoire lors du lancement de l'application; on gagne donc en place disque mais l'effet est dramatique sur la gestion mémoire !

  • L'optimisation du code: ça ne s'invente pas, mais y'a des programmeurs qui aiment copier/coller le code pour bien distinguer les étapes d'un programme, et d'autres qui préfère éliminer toute trace de redondance dans le code quitte à rendre le code moins évident à comprendre...à votre avis lequel produit les plus petits exe ?

  • L'optimisation des données: et oui, en quelques cliques vous pouvez placer un Bitmap dans un TImage en alignement alClient sur un TForm, et vous voilà avec une superbe image de fond sur la fenêtre...un copier/coller de l'image et voilà que l'image est sur toutes les fenêtres !
    L'effet est superbe, l'exe aussi; que ce passe-t-il dans ce genre de projet ? Chaque fenêtre du projet (donc chaque .DFM) contiendra une copie de l'image. Placez 10 fenêtres et vous aurez 10 copies du même bitmap dans l'exe final !

    Dans ce cas d'école, il faudrait créer une fiche modèle (avec l'image) dont hériteraient toutes les autres - et hop ! on divise par 10 la taille du projet !
    Il faut savoir aussi que le format Bitmap n'est pas (ou peu en RLE) compressé...commencez par réduire le nombre de couleurs du bitmap (pourquoi créer un bitmap en 24bits pour afficher 3 couleurs !), ou mieux choisissez n'importe quel autre format d'image, quitte à devoir charger l'image "à la main" depuis une resource !

    Pensez aussi à ZIPER vos données ! J'ai réalisé un unité UnZIP qui permet de décompressé un TStream vers un autre...voir BDE Inst.