Wie erklärt sich diese EXE-Größe

[alfware17]

Code: Alles auswählen

begin
  writeln('weiter mit Readln');
  Readln;
  Writeln('OK');
end.

Mein FPC (3.2.2) erzeugt daraus eine EXE von 34KB, u.a. 28.752 Bytes Code und 1.322 Bytes Data.
Ich habe gar keine Variablen? Und was wird da vom System alles eingebunden, ich nehme mal an es gibt einige Units, die ich nicht ausschließen kann?

Hintergrund meiner Frage, ich wollte ein bißchen mit meiner STDIO-Unit herumexperimentieren, wo ich den Verdacht hatte, daß sie meine Programme "dick" macht.
Nun sehe ich aber, es sind schon 34KB obwohl die Unit gar nicht drin ist. Mit Einbinden werden es 47KB, mit Aufruf einer Funktion dann 48KB.
Ich frage mich nun nur ob der 34KB, über die anderen 13/14KB habe ich beschlossen mir keinen Kopf mehr zu machen.
Obwohl ich es am Wochenende durchaus auf die harte Tour mal durchprobiert hatte (die Unit ist eigentlich 31.000 Quelltext-Bytes groß und ich hatte mal alles schrittweise rausgeworfen was nicht benutzt wird, es blieb aber immer bei ca 160KB EXE-Größe, egal wie viel ich gestrichen hatte, das heißt FPC macht da eigentlich einen effektiven Job und
übernimmt echt nur die aufgerufenen Funkltionen).

[af0815]

https://forum.lazarus.freepascal.org/in ... ic=54079.0

Siehe Framework Costs:
https://wiki.freepascal.org/Size_Matters

Auch der Punkt "Comparisons with GCC" Erklärt noch tiefergehend.

[Mathias]

Wen man noch den Parameter -XX verwendet, kann man die EXE noch um einiges zerkleiner. Ich habe es gerade mit meinem Mediaplayer welcher GTK4 nativ verwendet. Meine exe von 2.1MB auf 324KB runtergedrückt.
Selbstverständlich, habe ich Debugging und sonstige Prüfungen deaktiviert.
Getestet unter Linux.

[Warf]

Die kurze Antwort ist: jedes Pascal Programm bindet die System unit ein, die sehr viel standard Funktionalität mit sich bringt (z.B. handeln von Dateien, Klassen Infrastruktur, RTTI, Managed Typen, etc.) ohne das funktionieren die Hälfte der sprachfeatures von Pascal nicht (im Grunde alles was über das Featureset von C hinausgeht) plus deine Programme sind einfach nur nutzlos weil sie nicht mit der Außenwelt (z. B. Über Dateien) interagieren können.

In C ist das z.T. vergleichbar mit der libc die viele vergleichbare Funktionen bereitstellt. Der unterschied zu C ist, die libc ist als Bibliothek vom Betriebssystem gestellt, während der FPC die ganzen Funktionalitäten in das Programm kompiliert.

Als Extrembeispiel nimm das folgende Basv Programm:

Code: Alles auswählen

echo Hello World

Das ist nur 16 bytes groß, viel Glück ein kleineres Programm in Pascal oder sogar C zu schreiben.
Aber das liegt daran das die ganze Funktionalität die dahinter steht das laufbar zu machen in der bash steckt die vorinstalliert ist, nicht in dem Programm.

Das hat übrigens ein paar Nebeneffekte. Zum einen weil der Linux Kernel was syscalls angeht recht stabil ist, laufen Pascal Programme auf ewig alten Linux Versionen. Die LibC ist aber nicht so Abi stabil, weshalb ein modernes C Programm nicht mit der LibC eines uralt Linux funktioniert.
Dafür ist der FPC code sehr generisch während die lokale LibC Version extrem optimiert sein kann. Ein schöner Vergleich dafür ist der performance unterschied zwischen memcpy in C und Move in Pascal.

Es ist also nicht so als wäre eine Sache strikt besser als die andere

[Ich934]

Danke für die ausführliche Erklärung. Bisher war mir die Größe relativ egal, aber das kann sich ja ändern.

Ich hab mir jetzt das Thema Smart Linking in der Doku angeschaut. Wenn ich das richtig verstanden habe, wird nur das integriert, was wirklich benötigt wird. Die Abhängigkeiten im Code werden also reduziert. Als Ergebnis erhalte ich ein kleineres Binary, welches auch noch schnell geladen wird. Dafür dauert der Kompilierungsvorgang länger. Das wäre mir egal, da ich ja eh Debug und Release Versionen habe und wenn Release länger dauert zum Kompilieren ist das halt so.

Die Frage ist jetzt, ob ich hier noch andere Probleme/Nachteile erhalte, wenn ich das so mache?

Vielen Dank

[alfware17]

Danke euch für die Erklärungen - und im Hinterkopf hat man immer schon sowas, daß bei Pascal ein größeres Stück des Laufzeitsystems mit dabei ist. In meinem Fall die Unit System, auch wenn ich sie nicht sehen kann. Der Vergleich mit C ist natürlich unfair - ich habe im Winter etwas mit MingW herumexsperimentiert und die EXEn (auch Fortran, Ada, C) sind da alle kleiner, natürlich um den Preis daß irgendwo noch ein paar RTL sein müssen, im Zweifel sogar DLL anwesend sein müssen.

Mir ging es nur darum - mein eigentliches Programm mit 2000 Zeilen plus 3 Units ist in den vergangenen Jahren von 125 KB auf 160 KB gewachsen, ohne daß nennenswerter Code hinzukam im Hauptprogramm. OK 2-10B kommen irgendwie vom FPC, nicht schlimm. Nur sind eben meine Units gewachsen. Und da wollte ich sie entwirren, teilen und nebenbei mal schauen, ob das Auswirkungen hat. Lektion gelernt: nicht aufgerufene Prozeduren aus den Units haben keinen Einfluß, ich kann zwar teilen (fremde Prozeduren müssen nicht in jedem Projekt in der STDIO sein), muß es aber nicht wegen Größe. Nebenbei bemerkt ist das auch gar nicht so einfach, wenn man thematische und technische Zusammenhänge betrachtet. Aber immerhin, 10.000 von 30.000 Zeilen habe ich ausgelagert (in dem entsprechenden Programm blieb die EXE Größe bei 160 KB). Meine Ursache, Felder und Code in den BEGIN-END Sektions der Units habe ich auch gefunden und teils optimiert (sinnlos große Records gekürzt bzw auf dynamische Strukturen umgestellt). Blieb eben noch der "Rest" der 35 KB eines "leeren" Programms. was mir im Vergleich zu den 160 KB des echt vollen Programms viel vorkam. Aber nun habe ich die Erklärung, danke.

Und ja, ich habe auch schon mal in den Bereichen smartlink und debug-Informationen geschaut und ich weiß, richtige Lazarus-Programme fangen bei 1 bis mehreren MB erst an.
Nur ging es hier um reines Batch FPC. Ich bin ein komischer Mensch und verzichte zB bei den 32bit Versionen sogar auf die Sysutils, die CRT sowieso (weil ich mit den Umlauten auf Kriegspfad bin) und schreibe mir im Zweifel sogar eigene Units, die ich dann in 16 bit Turbo Pascal mit verwenden kann. Davon gehe ich nur weg, wenn ich von vorneherein davon ausgehen kann, daß das Zielsystem dann doch Win 64bit sein wird und 32bit oder 16bit eher ausgeschlossen.
Aber es hilft und übt! DIe letzte oben erwähnte Umstellung der BEGIN-END Sektion in meiner Unit mußte ich machen, weil ich zuviel Funktionen in meine RECORDs gelegt hatte und die dann "zu dick" für das Datensegment von Turbo wurden. Beispiel: ich hatte einen RECORD von ein paar Hundert Byte mit "Momenten" sprich Zeitdifferenzen und -Formaten. 10 Stück und es ging immer gut, bis ich dann 6 weitere Doubles hinzufügte, was dann eben ein paar Hundert Byte und etwas zuviel bedeutete. Nachdenken und Neuentwurf: ich speichere mir nur 2 Doubles - Start und Ende - und lasse Pascal das im Bedarfsfall neu ausrechnen und muß nicht den ganzen Schrott mitschleppen. Und ich kann 100 Intervalle haben statt 10, endlich mal genug und kleiner wird die EXE auch noch....

[Jorg3000]

Tach!
Was habe ich mich früher dafür gefeiert, wenn ich durch manuelle Optimierungen irgendwo ein paar Bytes eingespart hatte. Die Gedanken waren darauf getrimmt, weil es für Computer der 1980er und 90er Jahr noch nötig war, sogar im Kleinen sehr auf Kapazitäten und Geschwindigkeit zu achten.

Und in den letzten Jahren habe ich hart an mir gearbeitet, diese völlig veralteten Denkmuster über Bord zu werfen, weil ich mich sonst tagelang im Klein-Klein verliere und ich dann für Wichtigeres keine Zeit mehr habe. Es kommt natürlich darauf an, ob man als Hobby programmiert, wo man Zeit ausfüllen will und sich am eigenen Tun erfreut (der Weg ist das Ziel) - oder ob man es beruflich macht, wo man in absehbarer Zeit ein Ergebnis vorlegen muss.

daß das Zielsystem dann doch Win 64bit sein wird und 32bit oder 16bit eher ausgeschlossen.

Wenn du nicht für Museumsstücke programmierst, sondern auf PCs der letzten 10 Jahre mit Win64 abzielst, ist es wirklich scheißegal, ob deine .exe 30 KB oder 300 KB oder 3 MB oder 30 MB groß ist. Es ist einfach fucking egal.

Heutzutage gibt es andere Prioritäten, nämlich dass ein Programm zuverlässig und sicher funktioniert.
Nichts ist schlimmer als ein kaputt-optimiertes Programm, das zwar schön schlank ist, aber unter bestimmten Umständen versagt, z.B. gelegentlich Datenmüll produziert - oder wie du schreibst: evtl. mit Umlauten nicht richtig umgehen kann, etc. Damit ist auf Dauer niemandem geholfen.

Aber ich erwische mich immer wieder, wie ich gerne und lange über das Optimieren von Bits und Bytes nachdenke, weil es mir seit meiner Jugend immer wieder Zufriedenheit bereitet.
Grüße, Jörg

[theo]

Als Extrembeispiel nimm das folgende Basv Programm:

Jetzt habe ich tatsächlich gegoogelt, was ein "Basv" Programm wohl sein mag.
-> Bourne-again shell

[alfware17]

Tach!
Was habe ich mich früher dafür gefeiert, wenn ich durch manuelle Optimierungen irgendwo ein paar Bytes eingespart hatte. Die Gedanken waren darauf getrimmt, weil es für Computer der 1980er und 90er Jahr noch nötig war, sogar im Kleinen sehr auf Kapazitäten und Geschwindigkeit zu achten.

Und in den letzten Jahren habe ich hart an mir gearbeitet, diese völlig veralteten Denkmuster über Bord zu werfen, weil ich mich sonst tagelang im Klein-Klein verliere und ich dann für Wichtigeres keine Zeit mehr habe. Es kommt natürlich darauf an, ob man als Hobby programmiert, wo man Zeit ausfüllen will und sich am eigenen Tun erfreut (der Weg ist das Ziel) - oder ob man es beruflich macht, wo man in absehbarer Zeit ein Ergebnis vorlegen muss.

daß das Zielsystem dann doch Win 64bit sein wird und 32bit oder 16bit eher ausgeschlossen.

Wenn du nicht für Museumsstücke programmierst, sondern auf PCs der letzten 10 Jahre mit Win64 abzielst, ist es wirklich scheißegal, ob deine .exe 30 KB oder 300 KB oder 3 MB oder 30 MB groß ist. Es ist einfach fucking egal.

Heutzutage gibt es andere Prioritäten, nämlich dass ein Programm zuverlässig und sicher funktioniert.
Nichts ist schlimmer als ein kaputt-optimiertes Programm, das zwar schön schlank ist, aber unter bestimmten Umständen versagt, z.B. gelegentlich Datenmüll produziert - oder wie du schreibst: evtl. mit Umlauten nicht richtig umgehen kann, etc. Damit ist auf Dauer niemandem geholfen.

Aber ich erwische mich immer wieder, wie ich gerne und lange über das Optimieren von Bits und Bytes nachdenke, weil es mir seit meiner Jugend immer wieder Zufriedenheit bereitet.
Grüße, Jörg

Nunja, ich bin zum Glück aus der Tretmühle heraus und "muß" nichts mehr abliefern - wenn ich ab und zu noch etwas repariere und pflege, dann in Programmiersprachen und Systemen, die weit älter sind als du und ich. Was ich aber nicht möchte und zwar keinesfalls möchte, sind die modernen, unübersichtlichen und mit der heißen Nadel gestrickten Frameworks und die eher zufällig zusammengeklickten Anwendungen, die weniger mit Informatik als mit Klickibunti zu tun haben. Und wo es gefühlt alle 2 Tage ein Zwangs-Update geben muß, weil Microsoft oder die Paketzusammenbauer die Leute bei der Stange halten wollen. Ich würde so ein 30 oder 300 MB großes Paket nun nicht unbedingt als Zeichen von Zuverlässigkeit und Komfort betrachten, von Sicherheit ganz zu schweigen im Zeitalter der befohlenen Backdoors. Vielleicht sind die Pakete heute nur deswegen so groß und komplex, damit ja niemand auch von den Experten die Backdoors findet. Aber das nur am Rande.

[Jorg3000]

Ich hatte dabei gar nicht an externe Frameworks o.ä. gedacht,
ich meinte eher, dass man sich heutzutage besser auf andere Anforderungen konzentriert als auf Byte-Ersparnisse, die heutzutage längst nicht mehr so wichtig sind.

Von externen Frameworks halte ich mich auch möglichst fern, denn ich kann nicht zusätzlich den Support für die Fehler in fremden Programmteilen übernehmen.

[Mathias]

Von externen Frameworks halte ich mich auch möglichst fern, denn ich kann nicht zusätzlich den Support für die Fehler in fremden Programmteilen übernehmen.

Da bin ich anderer Meinung, mir macht es nichts aus, clibs einzubinden. Da hat es viele gute, gepflegte und ausgereifte Sachen.

[alfware17]

Ich habe wahrscheinlich wieder das falsche Fremdwort benutzt und meinte neben den Frameworks vor allem so ein Zeug wie Microsofts .NET - wo also (nach meinem Verständnis) der Programmcode gar nicht compiliert wird sondern einfach nur mit riesigen RTL zusammen in eine EXE gesteckt und dann irgendwie interpretiert wird und der Programmierer eigentlich nur nicht viel mehr macht als zusammenklicken. Aber haut mich nicht - ich mußte das zum Glück niemals machen, mein professionelles Entwickler-Leben endet bei sowas wie Cobol und bestenfalls noch Java am Großrechner. Pascal/Lazarus mache ich nur privat aus Spaß an der Freude, wenn allerdings auch schon sehr lange...

[Mathias]

Ich habe wahrscheinlich wieder das falsche Fremdwort benutzt und meinte neben den Frameworks vor allem so ein Zeug wie Microsofts .NET - wo also (nach meinem Verständnis) der Programmcode gar nicht compiliert wird sondern einfach nur mit riesigen RTL zusammen in eine EXE gesteckt und dann irgendwie interpretiert wird und der Programmierer eigentlich nur nicht viel mehr macht als zusammenklicken.

Solchen Müll fasse ich auch nicht an, genau sowenig auch Python.
Da fange ich vorher an Rust zu coden.

[Warf]

Von externen Frameworks halte ich mich auch möglichst fern, denn ich kann nicht zusätzlich den Support für die Fehler in fremden Programmteilen übernehmen.

Naja, mit Lazarus benutzt man schon mal die RTL, FCL und LCL, wobei grade die RTL und FCL einen haufen Units Beinhalten die über die Jahre von sehr vielen contributern gesammelt wurden und z.T. seit der initialen Contribution nicht mehr wirklich angefasst wurden.

Also ich mag oftmals externe Bibliotheken nicht weil es nervtötend sein kann sie einzubinden, man schauen muss das sie Lizenzrechtlich kompatibel sind, etc.

Mit reinen Source Bibliotheken geht das ja noch, die kann man einfach als git submodule in sein git repo werfen und mit relativen Pfaden in Lazarus angeben. Solabd aber LPKs drin sind mit Visuellen Komponenten die in Lazarus installiert werden müssen, wirds schon kompliziert. Und es gibt nichts schöneres ein Programm mit Lazarus zu öffnen und erst mal 10 millionen Meldungen über nicht gefundene Komponeten wegklicken zu dürfen

Ich habe wahrscheinlich wieder das falsche Fremdwort benutzt und meinte neben den Frameworks vor allem so ein Zeug wie Microsofts .NET - wo also (nach meinem Verständnis) der Programmcode gar nicht compiliert wird sondern einfach nur mit riesigen RTL zusammen in eine EXE gesteckt und dann irgendwie interpretiert wird und der Programmierer eigentlich nur nicht viel mehr macht als zusammenklicken. Aber haut mich nicht - ich mußte das zum Glück niemals machen, mein professionelles Entwickler-Leben endet bei sowas wie Cobol und bestenfalls noch Java am Großrechner. Pascal/Lazarus mache ich nur privat aus Spaß an der Freude, wenn allerdings auch schon sehr lange...

Doch es wird Kompiliert, sogar auch zu Maschinencode, eben nur nicht zu dem Code deiner Maschine. .Net ganuso wie Java sind VM basierte Sprachen, also der Quellcode wird in eine Custom Assembly für eine VM, z.B. bei Java die JVM oder bei .Net die CLR kompiliert. Wenn du dann die Executable ausführst startest du praktisch eine Lightweight VM die dann das Programm ausführt.
Du kannst mit dem FPC deine Pascal Programme übrigens auch für die JVM kompilieren, das unterstüzt der FPC genauso wie x86_64 Win64 oder ARM Linux.

Das hat auch seine Vorteile, denn die VM wird eben nicht in die Exe gepackt sondern auf dem Zielsystem installiert. D.h. wenn du dein Programm für die JVM schreibst dann läuft es auf jedem Rechner der eine JVM installiert hat exakt gleich. Und die JVM gibt es für sehr viele Geräte, Radios, Fernseher, SmartPhones, PCs, selbst SmartCards wie Bankkarten oder deinem Reisepass, auf denen läuft das so genannte JavaCard OS, was auch im endeffekt eine Form der JVM (sog. Micro JVM) ist.