Sign in Join
Wiki copytemporary

Size Matters/fr: what changed

Revision 1 to 2. Removed lines have a minus sign; added lines have a plus sign.

OldNewLine
11# Introduction
22
33Cette page porte sur les tailles de binaires. Au fil des années il y a eu beaucoup de confusion sur les tailles binaires FPC et Lazarus. Avant de faire des remarques dans les listes de diffusion, SVP, lisez cette FAQ.
44
55La principale raison pour cette FAQ est que la plupart des discussions sur ce sujet ont tendance à tomber trop rapidement dans les détails. Aussi, l'opinion de gens qui crient "envahit" presque tout et obscurcit l'image globale souvent plus qu'il ne contribue à la clarté.
66
77## Règle générale, que sont les tailles réalistes actuels pour les binaires FPC/Lazarus ?
88
9-- <b>Tout ce qui est en dessous de 1 Mo n'est pas un problème</b>.
10- - Assurez-vous qu'ils sont correctement <b>dépouillés (stripped) et liés intelligemment</b> avant la mesure et que TOUTES les bibliothèques sont construites en utilisant la liaison intelligente.
11- - <b>NE PAS FAIRE DE binaires UPX par habitude</b>, a moins d'avoir de très bonnes raisons de le faire (voir en dessous). La taille est moins importante que la charge mémoire qu'un binaire décompressé provoque. La mémoire est plus chère que l'espace disque. La plupart des outils d'accès à distance implémente la compression dans leur tunnel.
9+- Tout ce qui est en dessous de 1 Mo n'est pas un problème.
10+ - Assurez-vous qu'ils sont correctement dépouillés (stripped) et liés intelligemment avant la mesure et que TOUTES les bibliothèques sont construites en utilisant la liaison intelligente.
11+ - NE PAS FAIRE DE binaires UPX par habitude, a moins d'avoir de très bonnes raisons de le faire (voir en dessous). La taille est moins importante que la charge mémoire qu'un binaire décompressé provoque. La mémoire est plus chère que l'espace disque. La plupart des outils d'accès à distance implémente la compression dans leur tunnel.
1212- Avec de petites apps, c'est plus dur à estimer. C'est parce que la taille exacte de la RTL dépend de l'OS. Toutefois, 100ko de binaire autonome qui fait quelque chose peut être fait en général en dessous de 50ko.
1313 - Sous windows 20k d'IHM utilisant des binaires ne sont pas un problème.
1414 - L'unité SysUtils contient l'internationalisation, des messages d'erreur en texte, la gestion des exceptions et d'autres trucs qui sont toujours liés quand cette unité est employée (penser à un total de 40-100k).
1515- Les apps Lazarus sur Windows font environ 500ko, mais grossissent rapidement à 1,5 Mo et de plus en plus avec les widgets Lazarus utilisés. Les apps binaires Lazarus peuvent passer à plus de 100 Mo quand les infos de débogage sont liées dedans (comparable aux infos TD32 dans Delphi).
1616 - C'est un peu plus que lorsqu'on recompile avec une ancienne version de Delphi, et un peu moins qu'avec les versions modernes de Delphi (D2009+ la taille minimale de la RTL bondit fortement), c'est le prix de pour la compatibilité croisée de plate-forme et la maintenabilité des projets.
1717 - Quand le moment est atteint l'ajout de code supplémentaire n'introduit pas de nouvelles dépendances, cette croissance rapide disparaît.
1818 - Le point des 1,5Mo du dessus est une règle d'or. Il dépend beaucoup du style de création de votre IHM et du nombre de différents Widgets que vous utilisez et de leur complexité.
1919 - Pour les applications Lazarus, une partie du binaire n'est pas du code, la plupart sont des chaînes et des tables.
2020- Les simples binaires Linux/FreeBSD sont plus gros que les GCC correspondants. C'est parce qu'ils n'utilisent pas de bibliothèques partagées (ce que vous pouvez facilement voir `ldd ./xx`)
2121- Les binaires 64 bits sont toujours plus gros que leurs équivalents x86. En général, les plates-formes RISC génèrent aussi des binaires légèrement plus gros.
2222
2323## Pourquoi les binaires sont si gros ?
2424
25-<b>Réponse: Ils ne sont pas censés être grand.</b>
25+Réponse: Ils ne sont pas censés être grand.
2626
27-Si vous les <b>percevez</b> comme gros, alors
27+Si vous les percevez comme gros, alors
2828
2929- soit vous n'avez pas configuré FPC proprement, ou
3030- vous avez une attente irréaliste de la taille que devrait avoir le binaire
3131- vous essayer de faire quelque chose pour laquelle FPC n'est pas conçu.
3232
3333Le dernier est sans le moins probable des trois. Je vais traiter ces trois cas rapidement dans les prochains paragraphes.
3434
3535## Est-ce mauvais quand les binaires sont gros ?
3636
3737Bien, cela dépend de l'ampleur du parcours. Mais il est sûr de dire que presque personne ne devrait être inquiet d'avoir des binaires gros de quelques Mo ou même plus de 10 Mo pour des applications considérables.
3838
3939Cependant, il y a encore quelques catégories qui pourraient vouloir avoir un certain contrôle sur les fichiers binaires en les gardant petits.
4040
41411. Le monde de la programmation embarquée évidemment (et alors je ne veux pas dire les PC embarqués qui ont toujours des dizaines de Mo).
42422. les gens qui distribuent vraiment quotidiennement par modem
43433. Concours, mesures de performance
4444
4545Notez qu'une idée fausse souvent citée est celle que des binaires plus gros sont plus lents en fonctionnement. En général, cela n'est pas vrai, 'exotic last-cycle stuff as code cachelines'(non traduit) mis à part.
4646
4747### Embarqué
4848
4949Alors que Free Pascal est raisonnablement utilisable pour des usages embarqués ou de système, les décisions d'ingénierie de la version finale et de compromis sont basées sur les exigences de construction d'applications plus générales, bien que certaines des cibles les plus intégrées (comme DOS 16 bits ou ARM/AVR/MIPS (= PIC32) étendent cela à la limite.
5050
5151Si vous avez des besoins aussi spécialisés pour des objectifs plus réguliers, vous pouvez définir un projet dans l'ombre (quelque chose comme les versions spécialisées de certaines distros Linux qui sont disponibles). Ennuyer l'équipe FPC qui est déjà surchargée avec ces besoins spécifiques n'est pas une option, d'autant plus que la moitié des utilisateurs embarqués sérieux roulent de toutes façons.
5252
5353### distribution par modem
5454
5555Le cas du modem n'est pas seu1ement "télécharger depuis Internet" ou "mon shareware doit être aussi petit que possible", mais p.ex. dans mon ancien travail nous faisions un tas de déploiement vers nos clients et vers nos sites externes via le bureau distant sur le RNIS. Mais même avec un modem 56k, vous ne pouvez pas envoyer 1 Mo en moins de 5 minutes.
5656
5757Veillez à ne pas abuser de cet argument pour essayer de fournir un fondement rationnel mal placé pour une opinion émotionnelle sur la taille binaire. Si vous faites ce point, cela ne sert à rien sans une analyse statistique approfondie du pourcentage d'utilisateurs de modem réels que vous avez pour votre application (ma plupart des utilisateurs de logiciels ne téléchargent pas depuis Internet mais depuis les CD des magazines de shareware (NdT: ce point de vue n'est plus valbale actuellement).
5858
5959### Concours
6060
6161Une autre raison pour garder les binaires petits sont les comparaison de langages (comme le Language Shootout). Cependant ceci est plus comme résoudre un puzzle, et pas vraiment lié au génie logiciel responsable.
6262
6363## Configuration de compilateur incorrecte
6464
6565Je ne suis pas en train d'expliquer chaque aspect de la configuration du compilateur de manière détaillée, puisque c'est une FAQ, non un manuel. C'est juste un survol. Lire [manuals](http://www.freepascal.org/docs.html) et [[buildfaq]] de manière approfondie pour une information plus fondamentale.
6666
6767Il y a généralement plusieurs raisons de pourquoi un binaire semble plus gros qu'attendu. Cette FAQ couvre les raisons les plus courantes, en ordre décroissant de probabilité:
6868
69691. le binaire contient encore des informations de débogage.
70702. le programme n'a pas été (complétement) lié intelligemment.
71713. Le binaire inclut des unités contenant des sexctions d'initialisation qui execute beaucoup de code.
72724. vous liez statiquement des biblitohèques externes, plus qu'utilisez des liaisons dynamiques (bibliothèques partagées).
73735. L'optimisation n'est pas (complètement) activée.
74746. Le fichier de projet Lazarus (lpr) a des unités de paquet dans sa section uses (c'est fait automatiquement par Lazarus)
7575
7676Dans le futur, les liaisons partagées vers une bibliothèque d'exécution FPC et/ou Lazarus devrait changer cette image de manière significative. Bien sûr, cela vous aurez à distribuer une grosse DLL withe pleins d'autres trucs dedans qui vous amènera à des problèmes de versioning).
7777
7878Tout cela est encore dans le futur, il est donc difficile de quantifier l'impact sur les tailles binaires. Surtout parce que la liaison dynamique a également une surcharge de taille (en plus du code inutilisé dans la bibliothèque partagée).
7979
8080### Information de débogage
8181
82-Free Pascal utilise GDB comme débogueur et LD comme éditeur de liens. Ceux-ci travaillent avec des infos de débogage dans le binaire, dans l'ancien format <i>stabs</i> ou le plus récent <i>dwarf</i>. Les gens voient souvent p.ex. des binaires qui font 40 Mo. La bonne taille devrait être autour de 6Mo, le reste sont des informations de débogage (et peut-être 6 Mo pour de la liaison intelligente mal faite).
82+Free Pascal utilise GDB comme débogueur et LD comme éditeur de liens. Ceux-ci travaillent avec des infos de débogage dans le binaire, dans l'ancien format stabs ou le plus récent dwarf. Les gens voient souvent p.ex. des binaires qui font 40 Mo. La bonne taille devrait être autour de 6Mo, le reste sont des informations de débogage (et peut-être 6 Mo pour de la liaison intelligente mal faite).
8383
8484L'info de débogage Stabs est plutôt encombrante, mais a l'avantage d'être relativement indépendante du format binaire. Elle a été remplacée par DWARF sauf pour certaines plates-formes légataires.
8585
8686Il y a souvent confusion en ce qui concerne les informations de débogage, qui est causée par le strip dans de nombreuses versions win32 des binutils. Aussi certaines versions du binaire Win32 de strip n'élimine pas totalement les infos de débogage générées par FPC. Donc les gens bascule le drapeau tel que -Xs (ligne de commande Lazarus/IDE ou FPC) et suppose que cela marche alors que non. FPC a été adapté pour remédier à cela.
8787
88-Donc dans le doute, tenter <b>toujours</b> de faire le strip manuellement, et sur Windows, avec plusieurs binaires STRIP différents.
88+Donc dans le doute, tenter toujours de faire le strip manuellement, et sur Windows, avec plusieurs binaires STRIP différents.
8989
9090Ce genre de problème devient plus rare particulièrement sur Windows, depuis que l'éditeur de liens interne traite ces problèmes de façon plus consistante. Néanmoins (nez en moins ;-), il s'applique toujours pour les personnes qui utilisent des cibles exotiques pendant un certain temps encore.
9191
9292Vous pouvez utiliser le système de Strip pour livrer la même construction entre la version allégée (strippée) pour l'utilisateur et conserver la version complète (non strippée) pour p.ex. l'interprétation des adresses de trace arrière. Ainsi, si vous faites des livraisons formelles, conservez toujours une copie complète du binaire que vous enverrez qui sera allégé.
9393
9494La conception de GDB lui-même vous laisse garder et utiliser les informations de débogage en dehors du fichier binaire (infos de débogage externes), dans un fichier séparé .gdb. La taille du binaire résultant n'est pas augmentée du fait des infos de débogage, et vous pouvez toujours réussir à déboguer le binaire. Vous n'avez pas besoin du fichier .dbg pour exécuter l'application, il est utilisé uniquement par le débogueur. Comme les infos de débogage sont externes, il est utile d'utiliser strip.
9595
9696Pour compiler votre application de cette façon, vous devriez utiliser la bascule -Xg ou l'option correspondante dans l'IHM de Lazarus : dans 'Projet\|Options du projet\|Options du compilateur\|Débogage', laissez 'Generate info for the debugger' active et activez 'Use external debug symbols file'.
9797
98-<figure>
99-<img src="BigExe_FR.png" title="BigExe_FR.png" />
100-<figcaption>BigExe_FR.png</figcaption>
101-</figure>
98+![](/wiki-images/c/cc/BigExe_FR.png)
10299
103100Une application avec une fenêtre vide pour Win32, compilée avec des infos de débogage externes doit occuper environ 1 Mo, et le fichier .dbg environ 10 Mo.
104101
105102### Liaison intelligente
106103
107104*(main article principal: [[File size and smartlinking/fr|File size and smartlinking]])*
108105
109106La principe fondamental de la liaison intelligente est simple et bien connu : ne pas lier ce qui ne sert pas. Ceci a bien sûr un bon effet sur la taille du binaire.
110107
111108Pourtant, le compilateur est seulement un programme et n'a pas une boule de cristal magique pour voir ce qui est utilisé, aussi l'implémentation de base est plutôt comme cela :
112109
113110- Le compilateur divise le code en soi-disant "sections" qui sont assez petites.
114111- Ensuite le compilateur détermine quelles sections sont utilisées ne employant la règle "si aucune étiquette dans cette section n'est utilisée alors elle peut être éliminée".
115112
116113Il y a quelques problèmes avec cette vision simpliste:
117114
118115- les méthodes virtuelles peuvent être implicitement appelées via leur VMTs. L'éditeur de liens GNU ne peut pas tracer des séquences à travers ces VMTs, donc elles sont toutes liées dans le binaire;
119116- Les tables pour les chaînes de ressource font référence à chaque constante de chaîne, et donc toutes les constantes de chaîne sont liées (une des raisons pour lesquelles sysutils est gros).
120117- Des symboles qui peuvent appelés depuis l'extérieur du binaire (c'est aussi possible pour les binaires ELF qui ne sont pas des bibliothèques) doivent être conservés. Cette dernière limitation est nécessaire pour éviter stripping des fonctions exportées depuis les bibliothèques partagées.
121118- Les fonctions et propriétés publiées, qui doivent être conservées, constituent un autre problème de ce type. Les références aux fonctions/propriétés publiées peuvent être construites à la volée en utilisant des opérations de chaîne, et le compilateur ne peut tracer cela. C'est l'un des inconvénients de la réflexion.
122119- Les propriétés publiées et les méthodes doivent être résolues en créant les noms de symboles en utilisant de la manipulation de chaîne, et doivent donc être liées si la classe est référencée n'importe où. Le code publié pourrait à son tour appeler un code privé/protégé/public et donc une inclusion assez importante.
123120
124121Un autre effet de bord important qui est logique (mais souvent oublié) est que cet algorithme liera tout ce qui est référencé dans les section initialization et finalization des unités, même si aucune fonctionnalité de ces unités n'est utilisée. Donc soyez prudent avec ce que vous utilisez.
125122
126-Quoi qu'il en soit, la plupart des problèmes liés à l'utilisation de la liaison intelligente proviennent du fait que pour le plus petit résultat, FPC nécessite généralement que "compile with smartlinking" soit activé <b> LORS DE LA COMPILATION DE CHAQUE ET DE CHAQUE UNITÉ, MÊME LA RTL</b>.
123+Quoi qu'il en soit, la plupart des problèmes liés à l'utilisation de la liaison intelligente proviennent du fait que pour le plus petit résultat, FPC nécessite généralement que "compile with smartlinking" soit activé LORS DE LA COMPILATION DE CHAQUE ET DE CHAQUE UNITÉ, MÊME LA RTL.
127124
128-La raison pour cela est simple. LD ne pouvait faire des liaisons «intelligentes» que des unités de la taille d’un fichier .o entier jusqu’à assez récemment. Cela signifie que pour chaque symbole un fichier .o séparé doit être fabriqué (et ensuite ces dizaines de milliers de fichiers .o sont archivés dans un des fichiers .a). C'est une tâche consommatrice de temps (et de mémoire du lieur), donc c'est optionnel et activé seulement pour les versions de livraison, pas pour les instantanés (snapshots). <b>Souvent les gens qui ont des problèmes avec la liaison intelligente utilise un instantané qui contient des RTL/FCL etc qui n'ont pas été liées intelligemment</b>. La seule solution consiste à recomplier le source avec la liaison intelligente activée (-CX). Voir [[buildfaq]] plus d'infos.
125+La raison pour cela est simple. LD ne pouvait faire des liaisons «intelligentes» que des unités de la taille d’un fichier .o entier jusqu’à assez récemment. Cela signifie que pour chaque symbole un fichier .o séparé doit être fabriqué (et ensuite ces dizaines de milliers de fichiers .o sont archivés dans un des fichiers .a). C'est une tâche consommatrice de temps (et de mémoire du lieur), donc c'est optionnel et activé seulement pour les versions de livraison, pas pour les instantanés (snapshots). Souvent les gens qui ont des problèmes avec la liaison intelligente utilise un instantané qui contient des RTL/FCL etc qui n'ont pas été liées intelligemment. La seule solution consiste à recomplier le source avec la liaison intelligente activée (-CX). Voir [[buildfaq]] plus d'infos.
129126
130127A l'avenir, ceci sera amélioré quand le compilateur émettra du code lié intelligemment par défaut, au moins pour les cibles principales. Ceci sera rendu possible par deux développements séparés. D'abord, LD l'éditeur de liens GNU peut maintenant lier intelligemment de manière plus fine (au moins sous Unix) en utilisant --gc-sections; ensuite l'arrivée de l'éditeur de liens interne à FPC (dans la brance 2.1.1) pourt toutes les plates-formes fonctionnant (wince/win32/win64). L'édition de liens intelligente utilisant LD --gc-sections a encore beaucoup de problèmes car la disposition exacte de l'assembleur et de nombreux détails concernant les tableaux doivent être recherchés, nous entrons souvent dans des problèmes typiques avec les développement GNU ici, les outils sont à peine testés (ou parfois même pas implémentés, voir le standard DWARF) en dehors de ce que GCC utilise/souligne. De plus, les versions des cibles non * nix sont souvent basées sur des versions plus anciennes (pensezà DOS, go32v2, amiga ici).
131128
132129L'éditeur de liens interne peut maintenant lier intelligemment Lazarus (17 secondes pour une liaison intelligente complète sur un Athlon64 3700+ utilisant environ 250 Mo de mémoire) ce qui est plutôt bon, mais seulement pour Windows et 2.1.1 pour le moment. L'éditeur de liens interne ouvre aussi la porte à des liaisons intelligentes plus avancées qui demande des connaissances spếcifiques à Pascal, comme abandonner une méthode virtuelle (20 % sur la taille du code des exemples Lazarus, 5 % sur l'EDI Lazarus en première estimation grossière), et traitant mieux les cjaîbne des ressource inutilisées. Tout ceci est en alpha, et les statistiques du dessus sont probablement trop optimistes, puisque Lazarus ne travaille pas encore avec ces optimisations.
133130
134131Pendant une discussion sur Stack Overflow, certains [détails extra](https://stackoverflow.com/questions/4519726/delphi-which-are-the-downsides-of-having-unused-units-listed-in-the-uses-clause/4519894#4519894) viennent en avant (et la plupart les mêmes pour FPC comme pour Delphi, au moins sous Windows) :
135132
136133### Sections initialization et finalization
137134
138135Si vous incluez une unité en section *USES*, même quand il s'agit de USES indirects à travers une unité différente, alors SI l'unité contient des sections initialization ou finalization, ce code et ses dépendances sont toujours liés.
139136
140137Une unité pour laquelle c'est important est sysutils. Conformément à la compatibilité Delphi, sysutils convertit les erreurs d'exécution en exceptions avec un message textuel. Toutes les chaînes de sysutils réunies sont un peu volumineuses, il n'y a rien qui puisse être fait contre cela, à part de retirer un paquet d'initialisations de sysutils qui la rendra incompatible avc Delphi. C'est donc plus une chose pour une version embarquée, si une telle équipe se portait volontaire.
141138
142139### Binaires statiques
143140
144141*(main article: [[Lazarus/FPC Libraries/fr|Lazarus/FPC Libraries]])*
145142
146143On peut aussi faire des binaires totalement statiques sur chaque système d'exploitation, en incorporant toutes les bibliothèques dans le binaire. Cela est fait en général pour faciliter le déploiement, mais cela produit par là-même d'énormes binaires. Puisqu'il s'agit du "territoire des sorciers" (wizard territory), je ne le mentionne que par souci d'exhaustivité. Les personnes qui font cela le font en connaissance de cause, nous l'espèrons.
147144
148145Au lieu de produire des binaires statiques, des programmeurs font de la liaison dynamique / partagée. Cela PEUT générer un binaire exécutable beaucoup, beaucoup plus petit. Pourtant, il existe des cas où le binaire devient plus gros, en particulier sur des architectures comme x86_64 où le PIC est activé par défaut. La liaison dynamique (Win32) et la liaison partagée (*nix) sont le même concept, mais leur fonctionnement en interne est différent, comm cela peut être vu par le fait que les systèmes *nix ont besoin des bibliothèques partagées sur l'hôte pour faire le lien (croisé), alors que pour lier un binaire Windows vous n'avez pas besoin des DLLs nécessaires sur le système.
149146
150147### Optimisation
151148
152149L'optimisation peut également réduire un peu la taille du code. Le code optimisé est généralement plus serré (mais seulement en dixième de pourcent). Assurez-vous d'utliser l'option -O3. Voir aussi [[Whole Program Optimization/fr|Optimisation globale de programme]] pour davantage de réduction de la taille du code.
153150
154151### Fichier lpr de Lazarus
155152
156153Dans Lazarus, si vous ajoutez un paquet à votre projet/fiche, vous obtenez que l'enregistrement de son unité est ajouté au fichier lpr. Le fichier lpr n'est normalement pas ouvert. Si vous voulez l'éditer, vous l'ouvrez d'abord (via Projet\|Voir le code source du projet). Ensuite vous retirez toutes les unités non nécessaires telles que les interfaces, les fiches, les seules fiches requises sont vos propres unités de fiches, toutes les autres choses ne sont pas nécessaires mais vous devez vous assurez de ne pas supprimer d'unité qui enregistre des choses telles que des lecteurs d'images (jpeg) ou des cas de test. (Ndt: C'est cependant un exercice risqué car cela supposerait de connaître l'évolution future des unités utilisées)
157154
158155Vous économisez alors des mégaoctets ET quelques dépendance en liaison aussi si vous utilisez des gros paquets (tels que glscene).
159156
160157Ce type de comportement est typique pour les bibliothèques qui font beaucoup de section d'initialisation d'unités. Remarquez que peu importe où elles sont utilisées (lpr ou unité normale). Bien sûr, la liaison intelligente essaie de minimiser ces effets.
161158
162159## Problèmes 2.2.0
163160
164161(non traduit car sans doute obsolète bien que non vérifié) There appear to be some size problems in FPC 2.2.0 *is this still relevant for 2.6.x/2.7.x?* Note that these remarks hold for the default setup with internal linker enabled.
165162
166163- It seems that FPC 2.2.0 doesn't strip if any -g option is used to compile the main program. This contrary to earlier versions where -Xs had priority over -g
167164- It seems that FPC 2.2.0 doesn't always smartlink when crosscompiling. This can be problematic when compiling for windows, not only because of size, but also because dependencies are created to functions that might not exist.
168165
169166## UPX
170167
171168(non traduit, version 2.6 trop ancienne) **Note: UPX support in makefiles, and the distribution of upx by FPC ceased after 2.6.0. New releases of FPC won't package upx any more**
172169
173170The whole strange UPX cult originates mostly from a mindless pursuit of minimal binary sizes. In reality UPX is a tool with advantages and disadvantages.
174171
175172The advantages are:
176173
1771741. The decompression is easy for the user because it is self-contained
1781752. Some size savings are made if (and only if) the size criterion is based on the binary size itself (as happens in demo contests). However, especially in the lowest classes it might be worthwhile to minimize the RTL manually and to code your compression yourself, because you can probably get the decompression code much tighter for binaries that don't stress all aspects of the binary format.
1791763. For rarely used applications or applications run from removable media the disk space saving may outweigh the performance/memory penalties.
180177
181178The disadvantages are:
182179
1831801. worse compression (and also the decompression engine must be factored into _EACH_ binary) by archivers (like ZIP) and setup creation tools
1841812. decompression occurs on every execution, which introduces a startup delay.
1851823. Since Windows XP and later now feature a built-in decompressor for ZIP, the whole point of SFX goes away a bit.
1861834. UPXed binaries are increasingly being fingered by the malware heuristics of popular antivirus and mail-filtering apps.
1871845. An internally compressed binary can't be memorymapped by the OS, and must be loaded in its entirety. This means that the entire binary size is loaded into VM space (memory+swap), including resources.
1881856. You introduce another component (UPX, decompression stub) that can cause incompatibilities and problems.
189186
190187The memorymapping point needs some explanation: With normal binaries under Windows, all unused code remains in the .EXE, which is why Windows binaries are locked while running. Code is paged in 4k (8k on 64-bit) at a time as needed, and under low memory conditions is simply discarded (because it can be reloaded from the binary at any time). This also applies to graphic and string resources.
191188
192189A compressed binary must usually be decompressed in its entirety, to avoid badly affecting the compression ratio. So Windows has to decompress the whole binary on startup, and page the unused pages to the system swap, where they rot unused, and also take up extra swap space.
193190
194191## Coûts de cadre d'application (Framework)
195192
196193Un cadre d'application (ou cadriciel) réduit grandement la quantité de travail pour développer une application.
197194
198195Cela a cependant un coût, car un framework n'est pas une simple bibliothèque, mais plutôt un sous-système entier qui traite de l'interfaçage avec le monde extérieur. Un framework est conçu pour un ensemble d'applications qui peuvent accéder à de nombreuses fonctionnalités (même si une seule application ne le peut pas).
199196
200197Cependant, plus un framework peut accéder à des fonctionnalités, plus un certain sous-ensemble minimal devient grand. Pensze à l'internationalisation, au support des ressources, aux environnements de traduction (traduction sans recompilation), messages d'erreur siginificatifs pour les exceptions de base. Tout ceci est appelé les frais généraux du cadre d'application (framework overhead).
201198
202199La taille d'une application vide n'est pas due aux inefficiences du compilateur mais aux frais généraux du cadre d'application. Le compilateur ôtera le code inutilisé automatiquement, mais tout le code ne peut pas l'être. La conception du cadre d'application détermine quel code le compilateur est capable d'enlever lors de la compilation.
203200
204201Certains cadre d'application sont à l'origine de très petits frais généraux, alors que d'autres en amènent de plus gros. Tailles attendues pour les applications vides sur des cadriciels bien connus:
205202
206203- Aucun cadriciel (seulement la RTL): +/- 25kb
207204- Aucun cadriciel (RTL+sysutils seulement): +/- 100-125kb
208205- [[MSEide &amp; MSEgui/fr|MSEGUI]]: +/- 600kb
209206- Lazarus LCL: +/- 1000kb
210207- Free Vision: +/- 100kb
211208- [[KOL-CE/fr|Key Objects Library]]: +/- 50kb
212209
213210En bref, choisissez bien votre cadriciel. Un cadriciel puissant peut vous faire économiser beaucoup de temps, mais si l'espace est compté (cas du code embarqué), un cadriciel plus petit pourrait être un meilleur choix. Mais assurez d'avoir besoin de ce gain de place. De nombreux amateurs choisissent par habitude le plus petit cadriciel et finissent avec du code immaintenable puis arrêtent. Ce n'est pas drôle de maintenir des applications dans de multiples cadriciels pour gagner quelques ko.
214211
215212Remarquez par exemple que le cadriciel de Lazarus est relativement lourd du fait de l'utilisation de la RTTI et de l'introspection pour ses mécanismes de flux, et pas seulement la taille du source. la RTTI rend plus de code accessible en dégradant les performances de la liaison intelligente.
216213
217214# Attentes irréalistes
218215
219216Beaucoup de gens regardent la taille d'un binaire et s'écrient **Gonflé!**. Quand vous tentez d'argumenter avec eux, ils se cachent derrière des comparaisons (mais TP produit ...), ils ne disent jamais réellement 'pourquoi' ils sont besoin d'un binaire qui soit plus faibles sur tous les coûts. Certains d'entre eux ne réalisent même pas qu'un code 32-bit (maintenant 64-bit) est TOUJOURS plus gros qu'un code 16-bit (maintenant 32-bit) ou que l'indépendance à un SE a un coût ou ..., ou ..., ou ...
220217
221218Comme dit plus haut, avec la taille actuelle des disques durs, il n'y a pas de raison de garder les binaires avec des tailles très petites. les binaires FPC étant 10, 50 ou même 100% plus grands que ceux des compilateurs du précédent millénaire ne devraient pas avoir beaucoup d'importance. Un bon indicateur de ces visions est le sur-emploi franchement émotionnel et infondé d'UPX (voir au dessus), qui est un signe de la folie de la taille du binaire, puisque cela n'a pas de sens techniquement parlant.
222219
223220Alors d'où vient cette émotion ? S'agit-il simplement de résister au changement ou d'être des maniaques de contrôle ? Je n'ai jamais vu beaucoup de cause justifiée, sauf que parfois certains d'entre eux poussaient leurs propres bibliothèques inférieures et essayaient de gagner du terrain contre des bibliothèques bien établies basées sur des arguments de taille. Mais cela n'explique pas tous les cas, donc je pense que la taille binaire est vraiment le dernier artefact "640k devrait être suffisant pour n'importe qui" (Ndt: citation de Bill Gates). Même si ce n'est pas réel, mais juste mental.
224221
225222Une fausse révélation pour cela est que le nombre de correctifs réalistes dans ce domaine est proche de zéro, sinon zéro. Ce sont uniquement des discussions maillist, et des mods RTL triviaux qui ne gagnent presque rien et qui entravent sérieusement la création de vraies applications et la compatibilité (et je ne suis pas un maniaque de la compatibilité pour commencer). Personne ne s'assoit pendant quelques jours et fait une enquête approfondie et propose des correctifs. Il n'y a pas de RTL réduite entretenue en externe, pas de jeux de correctifs, etc., alors que ce serait extrêmement facile. **D'une manière ou d'une autre, les gens ne sont après le dernier octet que si c'est facile à réaliser, ou s'ils ont quelque chose de "moins gonflé" à promouvoir.**
226223
227224> **Note:** le paragraphe ci-dessus est toujours vrai, près de cinq ans après sa rédaction.
228225
229226Quoi qu'il en soit, les quelques personnes embarquées que je connais qui utilisent FPC de manière intensive ont toutes leurs propres bibliothèques personnalisées. Pour une personne, l'internationalisation compte même lorsqu'elle est intégrée (car elle parle une langue avec des accents), et les exceptions ne comptent pas, pour quelqu'un d'autre, les exigences sont encore différentes. Chacun a ses propres compromis et choix, et si l'espace est «vraiment» restreint, vous ne faites pas de compromis pour utiliser la distribution générale.
230227
231228Et oui, FPC pourrait utiliser quelques améliorations ici et là. Mais ceux-ci ne devraient pas nuire à la «programmation générale», à la nature multiplateforme du FPC, à la facilité d'utilisation et à être réaliste dans les besoins en main-d'œuvre. Les choses complexes prennent du temps. Les optimiseurs globaux ne tombent pas du ciel facilement
232229
233230## Comparaisons avec GCC
234231
235232Les comparaisons avec GCC sont un peu moins irréalistes. Même les développeurs se reflètent (et FPC) régulièrement dans GCC. Bien sûr, GCC est un monstre sponsorisé par une entreprise, qui est également le favori mondial de l'Open Source. Toutes les comparaisons ne sont pas raisonnables ou équitables. Même les compilateurs qui se basent sur GCC ne supportent pas toutes les fonctionnalités "c" de gcc fortement sponsorisées.
236233
237234Néanmoins, compte tenu des différences de taille des projets, FPC fait un travail étonnamment bon. La vitesse est correcte, sauf peut-être pour certains cas de calcul fortement scientifique, les tailles binaires et l'utilisation de la mémoire sont suffisantes voire meilleures en général, le nombre de plates-formes ne déçoit pas (même s'il est dommage qu'il manque de 'vraies' cibles embarquées).
238235
239236Un autre problème ici est que FreePascal lie généralement statiquement (car il n'est pas ABI stable et il est peu probable qu'il soit déjà sur le système cible même s'il l'était) son propre RTL. GCC établit des liens dynamiques avec les bibliothèques système. Cela fait que les très petits programmes (en termes de taille de source) créés avec fpc ont des binaires beaucoup plus grands que ceux créés avec GCC. Il convient de mentionner ici que la taille binaire n'a rien à voir avec l'empreinte mémoire du programme. FPC est généralement bien meilleur à cet égard que GCC.
240237
241238Pourtant, je pense que compte tenu des ressources, FPC se porte extraordinairement bien.
242239
243240## Comparaisons avec Delphi
244241
245242Dans les comparaisons avec Delphi, il faut garder à l'esprit que la conception de Delphi 32 bits provient de la période où beaucoup de gens n'avaient même pas de Pentium-I, et le développeur qui avait 32 Mo de RAM était chanceux. De plus, Delphi n'a pas été conçu pour être portable.
246243
247244Compte tenu de cela, Delphi a assez bien évolué, bien qu'il y ait toujours place à l'amélioration et à des réajustements qui corrigent les problèmes historiques et les compromis. (C'est un fait assez bien connu que beaucoup de routines d'assembleur dans les plus récents Delphi étaient plus lentes que leurs équivalents Pascal, car elles n'ont jamais été mises à jour pour les processeurs plus récents. On dit que cela n'a été corrigé que depuis Delphi 2006.)
248245
249246Pourtant, lentement sur le front du compilateur, FPC n'est plus le pauvre cousin de Delphi. Les comparaisons sont frontales, et le gain de FPC 2.1.1 sur Delphi devient lentement la règle, et non plus l'exception.
250247
251248Bien sûr, ce n'est que le compilateur de base. Dans d'autres domaines, il y a encore assez de travail à faire, bien que l'éditeur de liens interne aide beaucoup. Le débogueur ne sera pas amusant cependant :-) Aussi dans l'interopérabilité des langages (C ++, Obj C, JNI) et les bibliothèques partagées, il y a beaucoup de travail à faire, même dans le système de base.
252249
253250## Comparaisons avec .NET/Java
254251
255252Soyez très prudent dans les comparaisons avec ces systèmes compilés JIT: les programmes JIT-é ont des caractéristiques de référence différentes, et l'extrapolation des résultats des benchmarks aux programmes complets est également différente.
256253
257254Alors qu'un JIT peut parfois faire un excellent travail (en particulier dans les petits programmes qui consistent principalement en une seule boucle serrée), mais ce bon résultat ne s'adapte souvent pas. Dans l'ensemble, mon expérience est que le code compilé statiquement est généralement plus rapide dans la plupart des codes qui ne sont pas principalement liés par une boucle serrée hautement optimisable, malgré les nombreuses affirmations sur le net.
258255
259256Une source quantitative assez intéressante pour cela est cette entrée [Shootout faq](http://shootout.alioth.debian.org/gp4sandbox/faq.php#fullcpu). Une autre intéressante est [memory allocation in JVM/.NET](http://www.folding-hyperspace.com/program_tip_11.htm).
260257
261258Notez que depuis 2007, Java 6 a soudainement provoqué un saut significatif dans les évaluations de fusillade Java (Java shootout-ratings), et commence à toucher le fond des compilateurs natifs normaux. Cela montre qu'il faut être très prudent en faisant écho aux sentiments sur le Web (à la fois positifs et négatifs) et s'en tenir à sa propre mesure, avec les conditions aux limites ajustées au domaine d'application dans lequel vous vous trouvez.
262259
263260# Analyse de diverses options
264261
265262Tests sur Lazarus 0.9.29 avec FPC 2.4 (FPC 2.2.4 sous Windows).
266263
267264*Compilateur optimisé* signifie:
268265
269266- 1\. Projet\|Options du projet...\|Options du compilateur\|Compilation et édition de liens\|Lien intelligent (-CX) -\> Coché
270267- 2\. Projet\|Options du projet...\|Options du compilateur\|Débogage\| Décocher tout sauf 'Eliminer les symboles de l'exécutable Strip' (-Xs) -\> Coché
271268- 3\. Projet\|Options du projet...\|Options du compilateur\|Compilation et édition de liens\|Lier intelligemment (-XX) -\> Coché
272269
273270Le point le plus important semble être le 2. Pour une simple application la taille de l''exécutable serait de 1-3 Mo au lieu de 15-20 Mo.
274271
275272- 4\. (facultatif) Projet\|Options du projet...\|Options du compilateur\|Compilation et édition de liens\|Plus petit plutôt que plus rapide (-Os) -\> Coché (Avertissement: cela peut diminuer les performances en vitesse d'exécution).
276273
277274*Lazarus par défaut* signifie comme installé depuis le setup.
278275
279276*LCL sans information de débogage* signifie après reconstruction de lk'IDE Lazarus et de la LCL sans information de débogage (-g-).
280277
281-<TABLE WIDTH=642 BORDER=0 CELLPADDING=1 CELLSPACING=0>
282-
283-<TR VALIGN=TOP>
284-
285-<TH WIDTH=263>
286-
287-</TH>
288-
289-<TH WIDTH=14>
290-
291278   
292279
293-</TH>
294-
295-<TH WIDTH=111>
296-
297280Lazarus par défaut
298281
299-</TH>
300-
301-<TH WIDTH=14>
302-
303282   
304283
305-</TH>
306-
307-<TH WIDTH=220>
308-
309284LCL sans information de débogage
310285
311-</TH>
312-
313-</TR>
314-
315-<TR VALIGN=TOP>
316-
317-<TD WIDTH=263>
318-
319-<U>Ubuntu 64 bits / Lazarus 64 bits</U>
320-
321-</TD>
322-
323-<TD COLSPAN=4 WIDTH=372>
324-
325-</TD>
326-
327-</TR>
328-
329-<TR VALIGN=TOP>
330-
331-<TD WIDTH=263>
286+Ubuntu 64 bits / Lazarus 64 bits
332287
333288Application par défaut
334289
335-</TD>
336-
337-<TD WIDTH=14>
338-
339290   
340291
341-</TD>
342-
343-<TD WIDTH=111>
344-
34529213,4  Mb
346293
347-</TD>
348-
349-<TD WIDTH=14>
350-
351294   
352295
353-</TD>
354-
355-<TD WIDTH=220>
356-
3572967,5 Mb / 8
358297
359-</TD>
360-
361-</TR>
362-
363-<TR VALIGN=TOP>
364-
365-<TD WIDTH=263>
366-
367298Compilateur optimisé
368299
369-</TD>
370-
371-<TD WIDTH=14>
372-
373300   
374301
375-</TD>
376-
377-<TD WIDTH=111>
378-
3793024,4 Mb
380303
381-</TD>
382-
383-<TD WIDTH=14>
384-
385304   
386305
387-</TD>
388-
389-<TD WIDTH=220>
390-
3913062,70 Mb (0.29svn FPC2.4 2,5)
392307
393-</TD>
394-
395-</TR>
396-
397-<TR VALIGN=TOP>
398-
399-<TD WIDTH=263>
400-
401308   
402309
403-</TD>
404-
405-<TD COLSPAN=4 WIDTH=372>
406-
407-</TD>
408-
409-</TR>
410-
411-<TR VALIGN=TOP>
412-
413-<TD WIDTH=263>
414-
415-<U>Ubuntu 32 bits / Lazarus 32 bits</U>
416-
417-</TD>
418-
419-<TD COLSPAN=4 WIDTH=372>
420-
421-</TD>
422-
423-</TR>
424-
425-<TR VALIGN=TOP>
426-
427-<TD WIDTH=263>
310+Ubuntu 32 bits / Lazarus 32 bits
428311
429312Application par défaut
430313
431-</TD>
432-
433-<TD WIDTH=14>
434-
435314   
436315
437-</TD>
438-
439-<TD WIDTH=111>
440-
44131619,6  Mb
442317
443-</TD>
444-
445-<TD WIDTH=14>
446-
447318   
448319
449-</TD>
450-
451-<TD WIDTH=220>
452-
4533205,7 Mb
454321
455-</TD>
456-
457-</TR>
458-
459-<TR VALIGN=TOP>
460-
461-<TD WIDTH=263>
462-
463322Compilateur optimisé
464323
465-</TD>
466-
467-<TD WIDTH=14>
468-
469324   
470325
471-</TD>
472-
473-<TD WIDTH=111>
474-
4753262,9 Mb
476327
477-</TD>
478-
479-<TD WIDTH=14>
480-
481328   
482329
483-</TD>
484-
485-<TD WIDTH=220>
486-
4873301,6 Mb
488331
489-</TD>
490-
491-</TR>
492-
493-<TR VALIGN=TOP>
494-
495-<TD WIDTH=263>
496-
497332   
498333
499-</TD>
500-
501-<TD COLSPAN=4 WIDTH=372>
502-
503-</TD>
504-
505-</TR>
506-
507-<TR VALIGN=TOP>
508-
509-<TD WIDTH=263>
510-
511-<U>Windows XP 32 bits / Lazarus 32 bits</U>
512-
513-</TD>
514-
515-<TD COLSPAN=4 WIDTH=372>
516-
517-</TD>
518-
519-</TR>
520-
521-<TR VALIGN=TOP>
522-
523-<TD WIDTH=263>
334+Windows XP 32 bits / Lazarus 32 bits
524335
525336Application par défaut
526337
527-</TD>
528-
529-<TD WIDTH=14>
530-
531338   
532339
533-</TD>
534-
535-<TD WIDTH=111>
536-
53734011,8 Mb
538341
539-</TD>
540-
541-<TD WIDTH=14>
542-
543342   
544343
545-</TD>
546-
547-<TD WIDTH=220>
548-
5493442,14 Mb
550345
551-</TD>
552-
553-</TR>
554-
555-<TR VALIGN=TOP>
556-
557-<TD WIDTH=263>
558-
559346Compilateur optimisé
560347
561-</TD>
562-
563-<TD WIDTH=14>
564-
565348   
566349
567-</TD>
568-
569-<TD WIDTH=111>
570-
5713501,62 Mb
572351
573-</TD>
574-
575-<TD WIDTH=14>
576-
577352   
578353
579-</TD>
580-
581-<TD WIDTH=220>
582-
5833541,50 Mb
584355
585-</TD>
586-
587-</TR>
588-
589-<TR VALIGN=TOP>
590-
591-<TD WIDTH=263>
592-
593356   
594357
595-</TD>
596-
597-<TD COLSPAN=4 WIDTH=372>
598-
599-</TD>
600-
601-</TR>
602-
603-<TR VALIGN=TOP>
604-
605-<TD WIDTH=263>
606-
607-<U>Windows Seven 64 bits / Lazarus 64 bits</U>
608-
609-</TD>
610-
611-<TD COLSPAN=4 WIDTH=372>
612-
613-</TD>
614-
615-</TR>
616-
617-<TR VALIGN=TOP>
618-
619-<TD WIDTH=263>
358+Windows Seven 64 bits / Lazarus 64 bits
620359
621360Application par défaut
622361
623-</TD>
624-
625-<TD WIDTH=14>
626-
627362   
628363
629-</TD>
630-
631-<TD WIDTH=111>
632-
63336412,3  Mb
634365
635-</TD>
636-
637-<TD WIDTH=14>
638-
639366   
640367
641-</TD>
642-
643-<TD WIDTH=220>
644-
6453683,20 Mb
646369
647-</TD>
648-
649-</TR>
650-
651-<TR VALIGN=TOP>
652-
653-<TD WIDTH=263>
654-
655370Compilateur optimisé
656371
657-</TD>
658-
659-<TD WIDTH=14>
660-
661372   
662373
663-</TD>
664-
665-<TD WIDTH=111>
666-
6673742,14 Mb
668375
669-</TD>
670-
671-<TD WIDTH=14>
672-
673376   
674377
675-</TD>
676-
677-<TD WIDTH=220>
678-
6793782,16 Mb
680-
681-</TD>
682-
683-</TR>
684-
685-</TABLE>
686379
687380# Voir aussi
688381
689382- [[File size and smartlinking/fr|Taille de fichier et liaison intelligente]]
690383- [[Lazarus Faq/fr|Lazarus FAQ - Pourquoi les binaires produits sont si gros ?]]
691384
692385<https://wiki.freepascal.org/>
693386
694387---
695388*From the Free Pascal wiki, page "Size Matters/fr", as it stood on 2020-12-05 after a change by E-ric, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).*

Back to history