Size Matters/de: what changed

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

Old	New		Line
1	1		(Dieser Artikel wird zur Zeit übersetzt...)
2	2
3	3		## Einleitung
4	4
5	5		Auf dieser Seite geht es um die Größe von Binärdateien. Die Größe der von Lazarus und dem FPC erstellten Binärdateien sorgten in der Vergangenheit für einige Verwirrung. Dieser Artikel soll hier Klarheit schaffen. Insbesondere soll gezeigt werden, wie die Größe der Binärdateien ohne großen Aufwand vermindert werden kann.
6	6
7	7		### Realistische Größen der von Lazarus/FPC erstellten Binärdateien
8	8
9		-	~~- <b>Dateigrößen unter 1MB sollten kein Problem darstellen!</b>.~~
	9	+	- Dateigrößen unter 1MB sollten kein Problem darstellen!.
10	10		- Stellen Sie sicher, dass Ihre Binärdateien mit der Smartlinking-Option erstellt wurden, und anschließend mit dem Befehl strip sämtliche Debuggerinformationen entfernt wurden. Stellen Sie insbesondere sicher, dass ALLE Bibliotheken mit der Smartlinking-Option erstellt wurden.
11		-	- <b>Komprimieren Sie NICHT standardmäßig Ihre Dateien mit UPX!</b>: Durch die UPX-Kompression werden die Dateien zwar kleiner - sie verbrauchen bei der Ausführung aber mehr Arbeitsspeicher. Bevor Sie Ihre Binärdateien mit UPX komprimieren, sollten Sie sicherstellen, dass auf den Zielsystemen ausreichend RAM zur Verfügung steht!
	11	+	- Komprimieren Sie NICHT standardmäßig Ihre Dateien mit UPX!: Durch die UPX-Kompression werden die Dateien zwar kleiner - sie verbrauchen bei der Ausführung aber mehr Arbeitsspeicher. Bevor Sie Ihre Binärdateien mit UPX komprimieren, sollten Sie sicherstellen, dass auf den Zielsystemen ausreichend RAM zur Verfügung steht!
12	12		- Bei kleinen Anwendungen spielt die systemabhängige Größe der RTL eine gewichtigere Rolle. Standalone binaries, die etwas (sinnvolles) machen, können in einer Größenordnung von 50–100 k erzeugt werden.
13	13		- Unter Windows ist es kein Problem, die Windows API benutzende Binärdateien zu erstellen, die nur 20 Kb groß sind.
14	14		- Die Unit Sysutils beinhaltet Internationalisierungen, Texte zur Fehlerbenachrichtigung, Routinen zum Abfangen von Ausnahmefehlern und viele andere Dinge, die stets in das zu erstellende Programm gelinkt werden, wenn die entsprechende Unit benutzt wird. Dadurch kann die Größe des erstellten Programms schätzungsweise um 40 bis 100 Kb anwachsen.
15	15		- Windows-Lazarus-Anwendungen sind ungefähr 500 Kb groß. Je nachdem, wie viele Komponenten der Benutzeroberfläche (widgets) verwendet werden, kann ihre Größe jedoch schnell anwachsen (\>1.5MB)
16	16		- Summa summarum sind Lazarus-Anwendungen etwas größer als entsprechende Delphi-Anwendungen. Dies ist der Preis, der für die große Plattforumunabhängigkeit bezahlt wird und die Wartbarkeit des Lazarus-Projektes garantiert.
17	17		- Das Wachstum der Binärdateien mit dem Zufügen neuer Komponenten/Units stagniert, wenn mit jedem zusätzlich verwendeten Code kein weiterer zusätzlicher Code aus der LCL verlinkt werden muss.
18	18		- Die Größe der Binärdateien hängt entscheidend von der Komplexität der Benutzeroberfläche Ihrer Programme ab.
19	19		- In Lazarusanwendungen (wie in Delphianwendungen auch) besteht die Binärdatei zu einem gewissen Prozentsatz aus Zeichenketten und Tabellen. Diese zu komprimieren hat keinen Sinn (wie bei UPX).
20	20		- Einfache Lazarus-Binärdateien sind unter Linux/FreeBSD größer als entsprechende GCC-Binärdateien, da sie keine gemeinsamen Bibliotheken (shared libraries) verwenden. (Die Bibliotheken können Sie über die Konsole mit dem Befehl "ldd ./Programmname" einsehen)
21	21		- 64-Bit-Binärdateien sind stets größer als X86-Dateien. Genauso ist der für RISC-Plattformen erstellte Code größer als der für CISC erstellte.
22	22
23	23		### Weshalb sind die Binärdateien derart groß?
24	24
25		-	Antwort: Bei <b>richtigen Einstellungen</b> sind die mit Lazarus kompilierten Binärdateien nicht außergewöhnlich groß. (Bemerkung: Der Begriff "groß" soll hier bedeuten: Größer als im vorhergegangenen Abschnitt geschildert)
	25	+	Antwort: Bei richtigen Einstellungen sind die mit Lazarus kompilierten Binärdateien nicht außergewöhnlich groß. (Bemerkung: Der Begriff "groß" soll hier bedeuten: Größer als im vorhergegangenen Abschnitt geschildert)
26	26
27	27		Sollten Sie nach dem Kompilieren "große" Binärdateien erhalten, so können die Gründe dafür also
28	28
29	29		- in einer falschen Konfiguration des FreePascal-Compilers,
30	30		- in einer unrealistischen Vorstellung von der Größe von Binärdateien ;)
31	31		- oder daran liegen, dass Sie den FPC für Zwecke benutzen, für die er nicht konzipiert wurde.
32	32
33	33		Der letzte Punkt ist der unwahrscheinlichste - der FPC ist hochflexibel. In den folgenden Paragraphen wird den möglichen Ursachen einer zu großen Binärdatei genauer nachgegangen.
34	34
35	35		### Über Framework
36	36
37	37		Eine Framework vermindert die mit der Entwicklung einer Anwendung verbundene Arbeit im hohen Maße.
38	38
39	39		Dies kommt aber auf seine Kosten, da ein Framework keine reine Bibliothek ist, sondern ein ganzes Subystem, dass damit handelt mit der aussenstehenden Welt angekoppelt zu sein/werden. Ein Framework ist für Applikationen enworfen, die eine Menge Funktionalität bedürfen, und der Bedarf an Applikationen die keine große Funktionalität bedürfen, sind kein oder ein sehr unwichtiges Gebiet für die Gestalter eines Frameworks
40	40
41	41		Dies heißt aber nun das eine leere Applikation in einem Framework relativ groß sein kann.
42	42
43	43		Die größe einer leeren Apllikation entsteht nicht von Compiler Ineffizienz, sondern das Framework Overhead. Der Compiler wird unbenützen Code automatisch entfernen, aber nicht alles kann automatisch entnommen werden. Die Ausgestaltung des Frameworks bestimmt welchen Code der Compiler zur Compilierzeit entfernen kann.
44	44
45	45		Einige Frameworks verursachen sehr wenig Overhead, einige verursachen eine Menge Overhead. Erwartete Binary-Größen für leere Applikationen bei bekannten Frameworks:
46	46
47	47		- Kein Framework: +/- 25KB
48	48		- MSEGUI: +/- 600KB
49	49		- Lazarus LCL: +/- 1000KB
50	50		- Free Vision: +/- 100KB
51	51		- Key Objects Library: +/- 50KB
52	52
53	53		Kurz gefasst, wählen sie ihr Framework sorgfältig. Ein leistungsstarkes Framework kann ihnen eine Menge Zeit sparen, aber, wenn der Speicher knapp ist, mag ein kleineres Framework die bessere Wahl sein. Aber seien sie sicher das sie wirklich weniger Platz benötigen. Viele Amateure wählen routinemäßig das kleinste Framework, und landen bei nicht wartbaren Anwendungen und geben auf.
54	54
55	55		### Sind große Binärdateien schlecht?
56	56
57	57		Das kommt ganz auf den Standpunkt an, von dem aus man die Sache betrachtet. Zunächst gilt es, den Begriff "groß" festzulegen. Im Vorhergegangenen Abschnitt haben wir einen kleinen Überblick über mögliche Größen von lazaruserstellte Binärdateien gegeben. Wir nennen nun eine Binärdatei groß, wenn sie deutlich über den angegebenen Werten liegt.
58	58
59	59		Obwohl kleine Binärdateien sicherlich überall wünschenswert sind, so ist es ein oft zitiertes Missverständnis, größere binäre Dateien seien langsamer in der Ausführung. Diese Behauptung ist schlichtweg falsch.
60	60
61	61		Es gibt allerdings einige Bereiche, in denen Binärdateien klein sein müssen:
62	62
63	63		1. In der Welt der Kleincomputer (PDAs, Handhelds, u.s.w.), wo der Speicherplatz begrenzt ist.
64	64		2. Wenn die Zielgruppe keine schnelle Anbindung ans Internet besitzt (z.B. im Fall von Modems)
65	65		3. Bei Benchmarks und Vergleiche der Leistungsfähigkeit diverser Compiler und diverser Programmiersprachen.
66	66
67	67		#### Eingebettete Systeme
68	68
69	69		Free Pascal kann auch für eingebettete Systeme produktiv eingesetzt werden. Die Entwicklung von Free Pascal orientiert sich jedoch sehr viel stärker an allgemeinen Anwendungen (auf Desktop-PCs). Für hoch spezialisierte Anwendungsgebiete, kann ein Schattenprojekt eingerichtet werden, welches sich genau auf diesen Fall beschränkt -- ähnlich wie es verschiedene Linux Distributionen für verschiedene Anwendungsgebiete gibt. Das FPC-Team mit dieser zusätzlichen Aufgabe zu belasten wäre keine gute Idee, besonders deshalb, weil die Hälfte der ernsthaft interessierten Benutzer ihren eigenen Weg gehen werden.
70	70
71	71		#### Verbreitung über Modems
72	72
73	73		Sollte Ihre Zielgruppe hauptsächlich über langsame Modems verfügen, lohnt sich natürlich der Gedanke, die Binärdateien so klein wie möglich zur Verfügung zu stellen. Jedoch wird das Argument Modem häufig überschätzt:
74	74
75	75		1\. Durch den zunehmenden Ausbau des Internets stehe immer größere Bandbreiten zur Verfügung. So benutzt ein immer kleiner werdender Anteil der Internetbenutzer ein Modem oder ISDN.\
76	76		2\. Die Downloadzeiten mit einem 56k-Modem werden häufig unterschätzt. Einige MB lassen sich in weniger als einer halben Stunde herunterladen.
77	77
78	78		#### Wettbewerbe
79	79
80	80		Ein anderer Vorteil kleiner Binärdateien ist das gute Abschneiden der Größe der Binärdateien der betrachteten Programmiersprache im Vergleich mit der Größe der Binärdateien anderer Programmiersprachen(like the Language Shootout). Wieauchimmer ist das mehr wie das lösen eines Puzzles, und nicht wirklich zusammenhängend mit vernünftiger Programmierung
81	81
82	82		### Mangelhafte Kompilerkonfiguration
83	83
84	84		Dieser Abschnitt ist dazu da, Ihnen einen kleinen Überblick über für Binärdateien günstige Konfigurationen und Einstellungen des Compilers zu geben. Wenn Sie mehr Hintergrundinformationen benötigen, klicken Sie auf die folgenden Links: [manuals](http://www.freepascal.org/docs.html) [buildfaq](http://www.stack.nl/~marcov/buildfaq.pdf)
85	85
86	86		Hinsichtlich der Kompilereinstellungen kann es mehrere Gründe für große Binärdateien geben. Im Einzelnen, mit abnehmender Wahrscheinlichkeit:
87	87
88	88		1. Die Binärdatei beinhaltet Debuginformationen.
89	89		2. Die Binärdatei wurde nicht vollständig mit Smartlinking erstellt.
90	90		3. In die Binärdatei wurden units eingebunden, deren Initialisierungsabschnitte sehr viel Programmcode beinhalten.
91	91		4. Sie linken alle (externen) Bibliotheken (libraries) statisch.
92	92		5. Die Codeoptimierung des Compilers ist nicht (vollständig) eingeschalten.
93	93		6. Die Lazarus Projektdatei (lpr) bindet im uses-Bereich nicht benötigte units ein.
94	94
95	95		Für zukünftige Versionen des FreePascal-Compilers ist die Funktion des "shared linking" eingeplant. Damit wird es möglich sein, noch wesentlich kleinere Binärdateien zu erstellen, als dies heute möglich ist. (Diese Methode birgt allerdings den Nachteil, dass diverse DLLs zusammen mit dem Programm übertragen werden müssen)
96	96
97	97		#### Debuginformationen
98	98
99	99		FreePascal hat keinen hauseigenen Debugger oder Linker. Stattdessen verwendet es für die entsprechenden Zwecke den GNU-Debugger (GDB) bzw. den LD. Diese Programme speichern die Debuginformationen innerhalb der Binärdateien ab und blähen diese dadurch auf. So kann ein 6 MB großes Programm MIT den Debuginformationen gut 40 MB groß sein.
100	100
101	101		Sie können die überflüssigen Debuginformationen mit einem kleinen Programm namens "strip" entfernen. Bitte beachten Sie, dass Windows von Hause aus ein Programm "strip" mitliefert, welches jedoch nur zur Entfernung eines Teils der Debuginformationen in der Lage ist. Benutzen Sie daher die Version des genannten Programms, die ab 2006 mit dem FPC mitgeliefert wird. Unter Windows befindet es sich im Lazarus-Ordner "lazarus\fpc\fpcversion\bin\i386-win32\\", unter Linux lässt es sich direkt von der Konsole aus ausführen. (Unter Linux im Ordner "/usr/bin/"). Gehen Sie wie folgt vor:
102	102
103	103		Geben Sie folgendes an der Konsole ein:
104	104
105	105		```DOS
106	106		strip --strip-all Dateiname
107	107		```
108	108
109	109		Dabei steht "Dateiname" für Pfad + Name der Binärdatei.
110	110
111	111		Versuchen Sie stets, die Debuginformationen auf diese manuelle Weise zu entfernen. Verwenden Sie stets die mit FPC/Lazarus mitgelieferte Version von strip - verwenden Sie niemals Versionen unbekannten oder unsicheren Ursprungs.
112	112
113	113		#### Smartlinking
114	114
115	115		Das Grundprinzip des Smartlinkings ist leicht einzusehen: Es wird nur genau der Code in die Binärdatei gelinkt, der auch vom Programm gebraucht wird. Dies beeinflusst die Größe der Datei außerordentlich positiv.
116	116
117	117		Der Compiler ist leider nicht in der Lage, herauszufinden, welcher Code nun wirklich für das zu kompilierende Programm verwendet wird. Vielmehr teilt er den Code in Codebereiche auf, und es ist dann Aufgabe des Linkers, zu entscheiden, welcher Bereich letzten Endes in die Binärdatei gelangt. Wenn kein Teil des Programms einen Codebereich benötigt oder auf ihn weist, wird dieser Bereich entfernt.
118	118
119	119		Diese Vorgehensweise bringt einige Probleme mit sich:
120	120
121		-	- Virtuelle Methoden können über die <abbr title="Virtual Method Table">VMT</abbr> implizit aufgerufen werden. Der GNU Linker kann Funktionsaufrufe nicht durch die <abbr title="Virtual Method Table">VMT</abbr> hindurch verfolgen. Also müssen alle virtuellen Methoden in das Programm gelinkt werden;
	121	+	- Virtuelle Methoden können über die VMT implizit aufgerufen werden. Der GNU Linker kann Funktionsaufrufe nicht durch die VMT hindurch verfolgen. Also müssen alle virtuellen Methoden in das Programm gelinkt werden;
122	122		- Die Tabellen für resource strings referenzieren jede einzelne String-Konstante. Daher werden alle String-Konstanten hinein gelinkt (ein Grund, warum die Unit SysUtils so groß ist).
123	123		- Symbole, die von außerhalb der Binärdatei erreichbar sind (dies ist auch für nicht Bibliotheks-ELF-Binärdateien möglich), müssen erhalten bleiben. Diese Einschränkung ist nötig um zu verhindern, dass exportierte Funktionen aus Bibliotheken entfernt werden.
124	124		- Eigenschaften (Properties) und Funktionen, die als published deklariert sind, können zur Laufzeit durch String-Operationen referenziert werden. Sie müssen daher mit eingelinkt werden. Diese Methoden können von sich aus anderen Code aufrufen, der als private/protected oder public deklariert ist und daher ebenfalls eingebunden werden muss.
125	125
126	126		Ein weiterer wichtiger Seiteneffekt, der zwar logisch ist, aber oft vergessen wird, ist dass dieser Algorithmus alles verlinken wird, das in dem initialization- oder finalization-Abschnitt einer Unit genutzt wird – selbst wenn nichts aus dieser Unit genutzt wird. Achten Sie also darauf, was sie alles in dem uses-Abschnitt angeben.
127	127
128	128		Smartlinkting kann am effektivsten durchgeführt werden, wenn jede Unit, einschließlich der RTL smartlinked kompiliert wurde.
129	129
130	130		Der Grund dafür ist einfach: LD konnte (bis vor kurzem) nur solche Units "smart" linken, die aus einem einzigen Object-File (.o) bestehen. Für jedes Symbol muss also ein eigenes Object-File erstellt werden. Alle Object-Files einer Unit (bis zu einigen Tausend) werden dann in einer Archiv-Datei (.a) zusammengefasst. Dieser ganze Prozess benötigt viel Zeit (und Speicher), und ist daher optional und nur für Release-Versionen (und nicht für Snapshots) eingeschaltet. Oft gibt es Probleme beim smartlinking in Verbindung mit einem Snapshot, der Units der RTL/FCL enthält, die nicht mit smartlinked kompiliert wurden. Die einzige Lösung ist, diese Units mit smartlinking (-CX) selbst neu zu übersetzen. Siehe buildfaq für weiter Informationen.
131	131
132	132		In the future this will be improved when the compiler will emit smartlinking code by default, at least for the main targets. This is made possible by two distinct developments. First, the GNU linker LD now can smartlink more finely grained (at least on Unix) using --gc-sections, second the arrival of the FPC internal linker (in the 2.1.1 branch) for all working Windows platforms (wince/win32/win64). The smartlinking using LD --gc-sections still has a lot of problems because the exact assembler layout and numerous details with respect to tables must be researched, we often run into the typical problem with GNU development software here, the tools are barely tested (or sometimes not even implemented, see DWARF standard) outside what GCC uses/stresses.
133	133
134	134		The internal linker can now smartlink Lazarus (17 seconds for a full smartlink on my Athlon64 3700+ using about 250MB memory) which is quite well, but is windows only and 2.1.1 for now. The internal linker also opens the door to more advanced smartlinking that requires Pascal specific knowledge, like leaving out unused virtual methods (20% code size on Lazarus examples, 5% on the Lazarus IDE as a rough first estimate), and being smarter about unused resourcestrings. This is all still in alpha, and above numbers are probably too optimistic, since Lazarus is not working with these optimizations yet.
135	135
136	136		#### Initialization and finalization sections
137	137
138	138		If you include a unit in USES section, even when USES'd indirectly via a different unit, then IF the unit contains initialization or finalization sections, that code and its dependancies is always linked in.
139	139
140	140		A unit for which this is important is sysutils. As per Delphi compatibility, sysutils converts runtime errors to exceptions with a textual message. All the strings in sysutils together are a bit bulky. There is nothing that can be done about this, except removing a lot of initialisation from sysutils that would make it delphi incompatible. So this is more something for a embedded release, if such a team would ever volunteer.
141	141
142	142		#### Static binaries
143	143
144	144		One can also make fully static binaries on any OS, incorporating all libraries into the binary. This is usually done to ease deployment, but has as tradeoff huge binaries. Since this is wizard territory I only mention this for the sake of completeness. People that can do this, hopefully know what they are doing.
145	145
146	146		#### Optimierung
147	147
148	148		Optimization can also shave off a bit of code size. Optimized code is usually tighter. (but only tenths of a percent) Make sure you use -O3.
149	149
150	150		#### Lazarus lpr Dateien
151	151
152	152		In Lazarus, if you add a package to your project/form you get it's registration unit added to the lpr file. The lpr file is not normally opened, if you want to edit it, first open it (via project -\> view source). Then remove all the unnecessary units (Interfaces, Forms, and YOUR FORM units are only required, anything else is useless there, but make sure you don't delete units that only need to register things, such as image readers (jpeg) or testcases).
153	153
154	154		You can save up to megabytes AND some linking dependencies too if you use big packages (such as glscene).
155	155
156	156		This kind of behaviour is typical for libraries that do a lot in the initialisation sections of units. Note that it doesn't matter where they are used (.lpr or a normal unit). Of course smartlinking tries to minimalize this effect
157	157
158	158		### 2.2.0 Probleme
159	159
160	160		I routinely crack down on size discussions, to keep some sanity in them. This faq was meant for that.
161	161
162	162		However lately I've seen some size problems that were not of the routine kind. I suspect FPC changed behavior due to the internal linker in 2.2.0+. Since I want to try to be fair, I'll list my suspicions here. Note that these remarks hold for the default setup with internal linker enabled.
163	163
164	164		- 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
165	165		- 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.
166	166
167	167		### UPX
168	168
169	169		[UPX](http://upx.sourceforge.net/) ist ein Programm, dass die Größe von Binärdateien durch Kompression erheblich vermindert. Dabei ist zu beachten, dass UPX neben Vorteilen auch Nachteile besitzt.
170	170
171	171		Die Vorteile sind:
172	172
173	173		1. Zur Ausführung UPX-komprimierter Binärdateien sind keine Dekompressionsprogramme notwendig, da UPX alle nötigen Algorithmen in die Binärdatei integriert.
174	174		2. UPX verkleinert die Größe Ihrer unkomprimierten Binärdateien erheblich. (Bitte beachten Sie, dass Sie noch kleinere Dateien erhalten, wenn Sie für die Komression von Binärdateien externe Programme verwenden)
175	175		3. Durch die Kompression benötigt die unkomprimierte Binärdatei weniger Platz auf Speichermedien.
176	176		4. Durch die mit UPX erreichten Dateigrößen können Sie diejenigen Benutzer zufriedenstellen, die eine Anwendung nach Ihrem Platzverbrauch werten.
177	177
178	178		Die Nachteile sind:
179	179
180	180		1. Da jede UPX-komprimierte Binärdatei den Dekompressionsalgorithmus enthält, sind die Kompressionsraten nicht so groß, wie sie mit Hilfe externer Programme erreicht werden könnten.
181	181		2. Mit jedem Aufruf einer UPX-komprimierten Binärdatei wird zunächst der komprimierte Teil der Anwendung entpackt, bevor er ausgeführt wird.
182	182		3. Seit dem viele Betriebssysteme ZIP-Dateien integriert und ohne Zusatzsoftware entpacken können, verliert die UPX-Kompression an Gewicht.
183	183		4. Da die windowsinterne Speicherverwaltung nicht optimal mit solchen intern komprimierten Binärdateien umgehen kann, wird bei der Ausführung die gesamte Binärdatei in den Speicher geladen. Dies kann eine zusätzliche Speicherbelastung des Arbeitsspeichers bedeuten.
184	184
185	185		Um den letzten Punkt näher zu erläutern: Bei geringem freien Arbeitsspeicher werden nur diejenigen Teile einer unkomprimierten Binärdatei in den Arbeitsspeicher geladen, die wirklich von der Anwendung gebraucht werden. Bei UPX-komprimierten Binärdateien muss sich stets die gesamte Binärdatei im Arbeitsspeicher befinden.
186	186
187	187		Wenn hohe Kompressionsraten erreicht werden sollen, muss die gesamte Binärdatei vor ihrer Ausführung in den Arbeitsspeicher hinein entpackt werden. Nicht benötigte Bereiche des Programms gelangen nach einiger Zeit in die Swap, und belegen hier unnötig Speicherplatz.
188	188
189	189		## Unrealistische Erwartungen
190	190
191	191		A lot of people simply look at the size of a binary and scream bloat!. When you try to argue with them, they hide behind comparisons (but TP only produces...), they never really say 'why' they need the binary to be smaller at all costs. Some of them don't even realise that 32-bit code is ALWAYS bigger than 16-bit code, or that OS independance comes at a price, or ...,or ..., or...
192	192
193	193		As said earlier, with the current HD sizes, there is not that much reason to keep binaries extremely small. FPC binaries being 10, 50 or even 100% larger than compilers of the previous millenium shouldn't matter much. A good indicator that these views are pretty emotional and wellfounded is the overuse of UPX (see above), which is a typical sign of binary-size madness, since technically it doesn't make much sense.
194	194
195	195		So where is this emotion coming from them? Is it just resisting change, or being control-freaks? I never saw much justified cause, except that sometimes some of them were pushing their own inferior libraries, and tried to gain ground against well established libs based on size arguments. But this doesn't explain all cases, so I think the binary size thing is really the last "640k should be enough for anybody" artefact. Even though not real, but just mental.
196	196
197	197		A dead giveway for that is that the number of realistic patches in this field is near zero, if not zero. It's all maillist discussion only, and trivial RTL mods that hardly gain everything, and seriously hamper making real applications and compability. (and I'm not a compability freak to begin with). There are no cut down RTLs externally maintained, no patch sets etc, while it would be extremely easy. Somehow people are only after the last byte if it is easy to achieve, or if they have something "less bloated" to promote.
198	198
199	199		Anyway, the few embedded people I know that use FPC intensively all have their own customized cut back libraries. For one person internationalisation matters (because he talks a language with accents), and exceptions do not, for somebody else requirements are different again. Each one has its own tradeoffs and choices, and if space is 'really' tight, you don't compromise to use the general release distro.
200	200
201	201		And yes, FPC could use some improvements here and there. But those shouldn't hurt the "general programming", the multiplatform nature of FPC, the ease of use and be realistic in manpower requirements. Complex things take time. Global optimizers don't fall from the sky readily made.
202	202
203	203		### Vergleiche mit GCC
204	204
205	205		Somewhat less unrealistic are comparisons with GCC. Even the developers mirror themselves (and FPC) routinely against gcc. Of course gcc is a corporate sponsored behemoth, who is also the Open Source's world favorite. Not all comparisons are reasonable or fair. Even compilers that base themselves on GCC don't support all heavily sponsored "c" gcc's functionality.
206	206
207	207		Nevertheless, considering the differences in project size, FPC does a surprisingly good job. Speed is ok, except maybe for some cases of heavily scientific calculating, binary sizes and memory use are sufficient or even better in general, the number of platforms doesn't disappoint (though it is a pity that 'real' embedded targets are missing).
208	208
209	209		Another issue here is that freepascal generally statically links (because it is not abi stable and would be unlikely to be on the target system already even if it was) its own rtl. GCC dynamically links against system libraries. This makes very small (in terms of source size) programs made with fpc have significantly larger binaries than those made with gcc. It's worth mentioning here, that the binary size has nothing to do with the memory footprint of the program. FPC is usually much better in this regard than gcc.
210	210
211	211		Still, I think that considering the resources, FPC is doing extraordinary well.
212	212
213	213		### Vergleiche mit Delphi
214	214
215	215		In comparisons with Delphi one should keep in mind that 32-bit Delphi's design originates in the period that a lot of people DIDN'T even have pentium-I's, and the developer that had 32MB RAM was a lucky one. Moreover Delphi was not designed to be portable.
216	216
217	217		Considering this, Delphi scaled pretty well, though there is always room for improvement, and readjustments that correct historical problems and tradeoffs. (it is a pretty well known fact that a lot of assembler routines in newer Delphi's were slower than their Pascal equivalents, because they were never updated for newer processors. Only the recent D2006 is said to have corrected this).
218	218
219	219		Still, slowly on the compiler front, FPC isn't Delphi's poor cousin anymore. The comparisons are head-on, and FPC 2.1.1 winning over Delphi is slowly getting the rule, and not the exception anymore.
220	220
221	221		Of course that is only the base compiler. In other fields there is still enough work to do, though the internal linker helps a lot. The debugger won't be fun though :-) Also in the language interoperability (C++, Obj C, JNI) and shared libraries is lots of work to do, even within the base system.
222	222
223	223		### Vergleiche mit .NET/Java
224	224
225	225		Be very carefull with comparisons to these JIT compiled systems, JITed programs have different benchmark characteristics and also extrapolating results from benchmarks to full programs is different.
226	226
227	227		While a JIT can do a great job sometimes (specially in small programs that mostly consist out of a single tight loop), but this good result often doesn't scale. Overall my experience is that statically compiled code is usually faster in most code that is not mainly bound by some highly optimizable tight loop, despite the numerous claims on the net otherwise.
228	228
229	229		A fairly interesting quantitative source for this is this[Shootout faq](http://shootout.alioth.debian.org/gp4sandbox/faq.php#fullcpu) entry. Another interesting one is [memory allocation in JVM/.NET](http://www.folding-hyperspace.com/program_tip_11.htm)\
230		-	\
231	230
232	231		---
233	232		From the Free Pascal wiki, page "Size Matters/de", as it stood on 2014-11-22 after a change by Olaf, 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).
234	233		Category: Deutsch

Back to history