Entwickler-Ecke

Programmierwerkzeuge - 12 MB große EXE bei kleinem Programm


GuaAck - Fr 30.10.20 21:07
Titel: 12 MB große EXE bei kleinem Programm
Hallo,

ich habe unter RADStudio (Delphi 10.3) ein Testprogramm gemacht um einzelne Stringfunktionen zu verstehen. Das Hauptform enthält ein TButton und ein TMemo, der Programmcode past auf etwa eine A4-Seite. Das Programm machte, was es soll. Durch Zufall habe ich gesehen, dass die EXE ca. 12 MB groß ist, meistens haben solche Kleinstprogramme um 2 MB. Ich habe keine Besonderheit in den Optionen finden können.

a) Ich habe die *.res gelöscht. Keine Änderung, die *.res wurd in gleicher Größe von 59 kB wieder erstellt.

b) Ich habe dann die *.dpr, *.pas, und *.dfm in ein neues Verzeichnis kopiert, RADStudio neu geöffnet dann mit Daten/Öffnen/Delphi-Projekt (*.dpr) das Projekt geladen und die EXE erzeugt. Diese läuft und ist nur 2,3 MB groß. Auffallend ist, dass die neue *.res Datei nur 2,4 kB groß ist gegenüber der alten *.res mit 59 kB.

c) Dann habe ich die alte Version geladen und den Linker die Segmentliste ausgeben lassen. Diese habe ich dann nach EXCEL gebracht und die Längen aller Segmente addiert: Das ergibt 2,1 MB.

Hat jemand eine Idee, wieso da ca. 10 MB hinzukommen und diese nicht in de Segmenttabelle ausgewiesen sind?

Viele Grüße
GuaAck


jaenicke - Sa 31.10.20 06:42

Vermutlich steht die Buildkonfiguration (in der Projektverwaltung rechts oben) auf Debug. Dann werden auch Debuginformationen mitgeliefert.


GuaAck - Sa 31.10.20 20:54

Hallo Jaenicke,

das habe ich probiert und bei der Version "12MB-EXE" ist die Release-Version tatsächlich um 10 MB kleiner als die Debug-Version und nur 60 kB größer als die Version "2,4MB-EXE". Danke also für den Tipp. Erstaunlich aber: Bei der Version "2,4MB-EXE" sind die *.exe für Debug- und Release-Version exakt gleich groß. Und ich habe es probiert, in der Release-Version kann man keine Breakpoints setzen, das geht nur in der Debug-Version.

Ich habe dann mal die *.dproj miteinander verglichen (Version "12MB-EXE": 47 kB, Version "2,4MB-EXE": 6,7 kB). Der größte Unterschied ist, dass in der Version "12MB-EXE" noch jede Menge drin steht zu Android,iphone und wohl anderen System, die mir nichts sagen. Das wird die Ursache sein: Da habe ich wohl irgendwann mal versehentlich angewählt, dass ich was plattformübergreifendes machen will. Deshalb ist in der Debug-Version wohl alles drin. Die Release-Version kann ja nur für ein Betriebssystem gelten, also wird da der überflüssige Kram für andere Betriebssysteme entfernt. Das würde auch erklären, warum die *.res so groß ist, die Resourcen werden wohl auch für jedes Betriebssystem individuell sein.

Was meinst Du, könnte das etwa so sein? Für mich wäre das eine mehr als ausreichende Erklärung, weitere "Forschung" würde ich da nicht unternehmen.

Viele Grüße
Günter


GuaAck - So 01.11.20 00:42

Nachtrag:

ich habe eben ein Minimalprogramm mit einem TButton und einem TMemo gemacht, bei Klick auf den Buttong wird das berühmte "Hello world" als Zeile in das Memo geschrieben. Diese Programm habe ich auf drei alternativen Wegen erstellt:

1. Datei/neu/Geräteübergreifende Anwendung
2. Datei/neu/Windows-VCL-Anwendung
3. Datei/öffnen/Delphi Project (*.dpr)

Die habe ich dann jeweils als Debug und Release erstellt.

Ergebnis:
1:
2:
3:
4:
5:
6:
1. Debug:   *.EXE: 30  MB, *.RES: 59  kB, *.dproj: 47 kB
   Release: *.EXE: 9,2 MB, *.RES: 59  kB, *.dproj: 47 kB
2. Debug:   *.EXE: 12  MB, *.RES: 59  kB, *.dproj: 46 kB
   Release: *.EXE: 2,4 MB, *.RES: 59  kB, *.dproj: 46 kB
3. Debug:   *.EXE: 2,4 MB, *.RES: 2,5 kB, *.dproj: 6  kB
   Release: *.EXE: 2,4 MB, *.RES: 2,5 kB, *.dproj: 6  kB

Damit scheint alles geklärt, genau das ist passiert: Meine bisherigen Delphi 7 - Programme habe ich über den Weg 1 umgestellt, nur das Testprogramm (12MB-EXE) habe ich neu über Weg 2 erstellt.

Bei dem Weg 2 sind in der *.dproj auch jede Menge Zeilen mit "Android" usw. enthalten. Unklar bleibt mir, wozu die zusätzlichen 10 MB gut sind.

Gruß
GuaAck

P.S.: Ich scheine eben eine falsche Taste erwischt zu haben, jedenfalls sieht es so aus, als ob ich die erste Hälfte dieses schon abgeschickt hätte, mal sehen.

Moderiert von user profile iconTh69: Code-Tags hinzugefügt
Moderiert von user profile iconTh69: doppelten Beitrag gelöscht


jaenicke - So 01.11.20 02:53

Liegt bei der kleinen Debug-Exe vielleicht daneben noch eine .tds Datei oder so? Vielleicht ist da eingestellt, dass die Debuginformationen in einer separaten Datei abgelegt werden sollen.


GuaAck - So 01.11.20 12:23

Nein, da ist nichts. Außer den Quellen *.dpr, *.pas,*.dfm und *.dproj gibt es nur *.res (2,4 kB), *.identcache (152 Bytes), *.local (52 Bytes) und die *.EXE (2,4 MB).

Ich habe auch c:\users nach *.tds durchsucht, nichts gefunden.

Für mich ist jetzt alles ok. 12 Mb sind ja heute auch kein Problem mehr und wenn ich es kompakter brauche, dann kann ich das jederzeit ganz schnell über den genannten Umweg ändern.

Vielen Dank für die Anregungen und das Löschen meines versehentlichen "Teilbeitrages",

viele Grüße
GuaAck


Sinspin - Mi 04.11.20 17:46

Ich habe hier etwas ähnliches. Unter XE2 war meine EXE release compiled 45MB groß. Nun unter RIO sind es 82MB! Release!
Übersetze ich debug version sind es 85MB. Da passt was nicht. Absolut nicht.

Noch krasser wird es bei einem der Plugins (dll). Das war unter XE2 6MB/15MB (release/debug) nun unter RIO sind es 38MB/120MB!
Diese kleine Dll wird jetzt also debug übersetzt sogar größer als das Hauptprogramm.
Ist mir aber egal. Was mich umtreibt sind die Größen unter release. Da ist beim Hauptprogramm ja nichtmal ein Unterschied zwischen Debug und Release.

Was ich mir nicht vorstellen kann dass DevExpress (wir sind von 18 unter XE2 auf 20 mit Umstieg auf RIO gewechselt) da jetzt fast 40 MB mehr verursacht. Das wäre schon etwas krass.

€Rechtschreibung ist etwas eingerostet.


Th69 - Mi 04.11.20 18:02

Verwendest du denn "Runtime Packages" oder hast du alles in der Anwendung einkompiliert (bzw. hinzugelinkt)? s.a. Delphi HowTo: Runtime-Packages [https://www.delphipraxis.net/171762-howto-runtime-packages.html]

Bei letzterem wird die EXE natürlich um so größer, je mehr Funktionalität du von den Packages benutzt (im Extremfall also alles).


Sinspin - Mi 04.11.20 19:58

Nein. Da sind keine Runtime Packages.
Das Plugin verwendet zwar ein paar Dialoge und die gleiche Funktionsbasis die es auch im Hauptprogramm gibt. Aber die da gibt es nur ein Fenster. Das Hauptprogramm hat mehr als 100.

Unter XE2 hat ja auch noch alles gepasst. Nur RIO lässt mich gerade etwas (ver)zweifeln. Die Dll wird regelmäßig erneuert und beim Programmstart aus dem Netzwerk geladen (wenn sie neu ist). Umso größer die ist um so länger muss der Nutzer warten.


Th69 - Mi 04.11.20 20:46

Wie groß (bzw. klein) wird denn die EXE, wenn du die "Runtime Packages" aktivierst?


jaenicke - Mi 04.11.20 22:05

Runtime Packages verkleinern zwar die Exe bzw. DLL, aber dafür muss man die Packages auch mitliefern und hat alle Nachteile, die BPLs nun einmal mitbringen (Performance, Abhängigkeiten, ...). Es gibt nicht umsonst den Begriff BPL Hölle.

Von daher ist das auch kein Allheilmittel.

Bei JCL/JVCL ist auch ein Unitanalyse-Tool dabei, das anzeigt welche Units mit welcher Größe einkompiliert werden. (Projekt --> Analyze project xyz)


Th69 - Do 05.11.20 10:07

Das ist von mir ja auch nur als Test gedacht (um zu sehen, wie groß die EXE ohne externen Code wird)...


jaenicke - Do 05.11.20 10:17

Wenn man die Runtime Packages denn einfach so aktiviert bekommt, kann man das natürlich machen. Das hat bei mir bei größeren Projekten aber leider nie ohne Probleme geklappt.


Sinspin - Do 05.11.20 16:17

So ist es. Mein Projekt hat mehr als 500KZeilen im Hauptmodul. Und Komponenten von ein paar Herstellern. Ich habe das letzte mal vor 10 Jahren versucht mit BPL zu übersetzen. Eher ernüchternd als Erfolgreich.
JVCL habe ich hier nicht mit drauf. Wir verwenden DevExpress. Ich schaue mal ob ich das Tool isolieren kann und einzeln installieren oder ausführen.


GuaAck - Fr 06.11.20 19:08

Hallo,

ich habe das eben mit den Laufzeit-Packages probiert. Also: Neues VCL-Projekt (1 Button, 1 TMemo, bei Knopfdruck "Hello World" in Memo).

Option "Mit Laufzeit-Packages linken" = false: (War Standard bei allen Einstellungen bisher)
Release: 2,4 MB
Debug: 12,4 MB

Option "Mit Laufzeit-Packages linken" = true:
Release: 92 kB (ja, kilo...)
Debug: 2,5 MB

Den Text "Mit Laufzeitpackes linken" finde ich in bezug auf true und false für missverständlich.

Das zur Info,
viele Grüße
GuaAck


jaenicke - Fr 06.11.20 22:38

user profile iconGuaAck hat folgendes geschrieben Zum zitierten Posting springen:
Den Text "Mit Laufzeitpackes linken" finde ich in bezug auf true und false für missverständlich.
Mit Laufzeit-Packages linken bedeutet, dass der Linker die Laufzeit-Packages einbindet, du also die kompilierten Packages quasi wie DLLs mitliefern musst. Entsprechend wird das Kompilat deutlich kleiner. Was ist daran falsch?


GuaAck - Sa 07.11.20 00:19

Hallo Jaenicke,

ich habe nicht geschrieben, dass es falsch sei, ich finde es missverständlich. Für mich bedeutet der Satz, dass Packages in die *.exe eingebunden werden und auf dem PC, auf dem das Programm ausgeführt wird, nicht vorhanden sein müssen. Deine - zutreffende - Interpretation ist auch logisch, wenn man den Satz als Gegenteil von "alle Packages linken" verteht. Wie gesagt, kann man falsch verstehen, habe ich eben.

Ich mache aber niemandem einen Vorwurf, die besten Textschreiber können nicht jede mögliche Fehlinterpretation vermeiden. Für mich wäre z. B. "Ohne Packages" klarer ("linken" ist entbehrlich, das ist ja die Rubrik). Wer weiß, wer das falsch verstehen würde.

Schönes Wochenende,
Gruß
GuuAck


jaenicke - Sa 07.11.20 09:14

Die Formulierung "Laufzeitpackages verwenden" wäre vermutlich am klarsten. Aber am sinnvollsten wäre wohl schlicht die Auswahl der Laufzeitpackages zu deaktivieren, wenn das Häkchen nicht gesetzt ist. Aber ich glaube nicht, dass an der Stelle Änderungen vorgenommen würden, da das schon ewig so ist.

In der Hilfe ist es übrigens noch einmal ausführlicher beschrieben.


Th69 - Sa 07.11.20 10:31

Danke GuaAck,

daran sieht man, daß bei dir ca. 7,5 MB (~= 12,4 MB - 2,5 MB - 2,4 MB) alleine für die Debug-Infos der externen Packages einkompiliert werden (und ähnlich wird es dann bei dem Projekt von Sinspin sein).
Wenn man es genau wissen möchte, könnte ein "PE Viewer" hier helfen, z.B. PE Explorer [http://www.pe-explorer.com] (with "Special support for Delphi applications"!).


Sinspin - Sa 07.11.20 12:24

Bei mir ist es witziger. Ich habe keine ernsthaften Größenunterschiede zwischen Debug und Release. Letzteres war bisher immer rund zwei drittel kleiner als Debug. Seit RIO ist das nicht mehr der Fall.
Bei einem meiner Plugins habe ich einen deutlichen Unterschied, wenngleich alles seit Umstieg auf RIO höllisch groß geworden ist. Andere Plugins mit nur einem Dialog habe ich bisher noch nicht getestet.


Th69 - Sa 07.11.20 12:47

Dann überprüfe mal deine Projekteinstellungen für Debug und Release. Hast du evtl. bei Release auch Debug-Infos aktiviert?


Sinspin - So 08.11.20 12:41

Da gibt es ein bisschen Magie in RIO! Selbst bei Übersetzung auf Release wurden scheinbar zufällig Debug Blocks mit übersetzt. Wenn man "einige male hin und her schaltet zwischen release/debug" dann geht es.
MadExcept ist ein bisschen hinterhältig und setzt auch unter release die debug Einstellungen von alleine wieder. Ich dachte erst das es auch für das setzen des DEBUG Schalters verantwortlich ist, stimmt aber nicht.
Trotz allen Debugeinstellungen korrekt aus und deaktiviertem MadExcept ist da nur ein Größenunterschied von 3MB.
Das deutet darauf hin dass beim compilieren irgendwas mitgenommen wird was nicht sollte, aber in den Projekt Optionen nicht auftaucht.
Ich werde weiter suchen und erstmal mit der Monster exe (Dinosaurier :gruebel: ?) leben.


jaenicke - So 08.11.20 15:42

user profile iconSinspin hat folgendes geschrieben Zum zitierten Posting springen:
MadExcept ist ein bisschen hinterhältig und setzt auch unter release die debug Einstellungen von alleine wieder.
Naja, irgendwo muss es die Informationen ja herbekommen. Wir verwenden Eurekalog, das die Daten in einem eigenen relativ kleinen Format in der Exe speichert.

Im Zweifelsfall müsstest du dir die .dproj Datei genauer anschauen oder sie umbenennen und neu erstellen lassen (und dann ggf. den Unterschied suchen). Vielleicht ist da mit der Vererbung von Einstellungen etwas durcheinander gekommen.


GuaAck - Mo 09.11.20 23:28

Hallo Sinspin,

probiere doch mal meinen oben beschrieben Weg: Alle Dateien löschen außer *.pas, *.dfm und *.dpr (und natürlich auch nicht eigene *.res usw.). Dann RADStudio öffen und über Datei/Öffenen/*.dpr-öffnen die *.dpr Datei öffnen. Gggf. Optionen (Suchpfade!) anpassen. Ich erhalte über diesen Weg immer viel kleinere *.exe als über allen anderen Wege (3 Mb statt 12 Mb). Wäre interessant, zu wissen, was bei Dir dabei passiert.

Gruß
GuaAck


jaenicke - Di 10.11.20 07:22

Wir setzen die Optionen so wie wir es brauchen. Von daher gibt es durchaus einige Projekte, bei denen die Release-Exe dadurch kleiner würde. Das ist bei uns aber Absicht, da wir durchaus auch Debuginformationen in diversen Release-Exen drin haben.

Zu allen großen Projekten erstellen wir im Buildprozess auf der Buildmaschine aus den Debuginformationen von Delphi die passenden .dbg Dateien, die Windows selbst, aber auch z.B. der Process Explorer, lesen kann. Dadurch können diese Tools dann Stacktraces extern bei Fehlern oder Analysen erzeugen. Im Zuge der Erzeugung der .dbg Datei werden die Debuginformationen dann aus der Exe herausgenommen und so erhalten wir dann die kleinen Exen obwohl die Debuginformationen vorher aktiviert waren.