Wie bekomme ich die exe kleiner?

[NicoleWagner]

Meine exe kann nicht viel, doch sie bringt 15 MB auf die Waage.
Ich habe schon alle DB-Komponenten entfernt. Doch die Liste, was noch "inkludiert" ist, die ist gar lange.
Wie bringe ich mein Programm am effizientesten auf eine kleine Größe?
Gibt es einen Weg, die IDE (XE 3 Professional), diese Arbeit machen zu lassen?

Danke!

[DieDolly]

Zitat:

Meine exe kann nicht viel, doch sie bringt 15 MB auf die Waage.

Stell erstmal im Projektexplorer die Build-Konfiguration von Debug auf Release um.

[Delphi-Laie]

Zitat:

Zitat von NicoleWagner (Beitrag 1456111)

Wie bringe ich mein Programm am effizientesten auf eine kleine Größe?

Darauf habe ich einen Antwortenblock in petto:

1. Möglichst kleine / frühe Delphiversion verwenden
2. NonVCL (eigentlich nur Luckies Domizil)
3. Nicht benötigte Units entfernen
4. benötigte Units abspecken, ggf. nur benötigten Code extrahieren und entsprechende Unit(s) entfernen
5. Debuginformationen in Compiler/Linker entfernen:
Projekt -> (Standard)Optionen -> Compiler
Haken bei
- Optimierung an
- bei [Laufzeitfehler] und [Debuggen] alles weg
6. Wohl in Projektdatei: RTTI:
{$weaklinkrtti on}
{$rtti explicit methods([]) properties([]) fields([])}
7. KOL-(System-)Units verwenden
8. Units ohne RTTI nochmals compilieren (lassen), sofern möglich
(9. upx)

[DieDolly]

Zitat:

Darauf habe ich einen Antwortenblock in petto:

Das würde ich aber nur in der Release-Konfiguration machen (und selbst hier braucht man es nicht). Nicht in der Debug.

[himitsu]

Delphi-Quellcode:

Nicht benötigte Units entfernen

hilft fast immer.
Eigentlich lässt der Delphi-Compiler alles weg, was nicht verwendet wurde,
aber in vielen Units gibt es einen großen Initialisazionsblock, wo Klassen initialisiert werden, aber damit werden sie auch "benutzt", selbst wenn sie nicht wirklich genutzt werden, aber da sie "benutzt" werden, ist deren Code somit immer im Programm drin, sobald diese Unit irgendwo eingebunden wurde.
Auch Ressourcen, die in diesen Units eingebunden werden, sind dann immer drin, da man leider nicht angeben kann, dass diese Ressoucen nur gelinkt werden sollen, wenn bestimmte Funktionen/Klassen einkompiliert wurden.

Das mit dem Initialisazionsblock ist die Schuld altmodischer/blöder Programmierer, denn hätten sie die Initialisation z.B. in einen ClassConstructor gelegt, dann wäre alles nur drin, wenn diese Klassen dann "wirklich" benutzt wurden.


Ansonsten sind natürlich solche Profile, wie Debug und Release, genau dafür da.
Eine Konfiguration für die Entwicklung und eine Andere für den normalen Betrieb.

[Sherlock]

Bist du fertig mit der Entwicklung? Sind alle Fehler draußen? Berichten die Anwender von einer hervorragenden Usability? Langweilst Du Dich? 15MB sind nicht groß. Gemessen an Terabyte Festplatten, Gigabyte Arbeitsspeicher und Gigabit Netzwerken schonmal gar nicht. In meinen Augen ist Exe-Größe etwas, das man getrost ans Ende der Entwicklung schieben kann. Du kannst natürlich noch den Weg der restlichen Welt gehen und winzige Exen durch die Beigabe von tausenden DLLs, BPLs und sonstigen Hilfsdateien, deren Versionierung ab dann minutiös beachtet werden will erkaufen. Ich würde es lassen. Administratoren übrigens, lieben monolithische Exen.

Sherlock

[Neumann]

Was bringt eine kleinere EXE? Platz sparen auf der Platte - eher uninteressant wenn man 10 MB sparen kann.

Wird das Programm schneller wenn die EXE kleiner ist - kann ich mir nicht vorstellen.

[KodeZwerg]

Am schmalsten wird es wenn Du auf No-VCL umsteigst.
Je nach Fall, mal mehr mal weniger kompliziert, Luckie kennt sich damit gut aus und hat super Einsteigerfreundliche Tutorials auf seiner Web-Page.
Da kann es schon vorkommen das aus Deiner 15MB Datei eine 50KB Datei wird.

Alternative I:
Downloade Dir einen exe-Packer wie UPX (z.Bsp.) und komprimier das Resultat.

Alternative II:
Komprimier mit 7zip oder RAR5 Deine Datei als SFX-Archiv, so bleibt der Transfer schmal aber beim Endverbraucher pumpt es sich wieder auf volle Größe aus.
Sollte in der heutigen Zeit kein Problem darstellen, Speicher ist billig :-D

[KodeZwerg]

Zitat:

Zitat von Neumann (Beitrag 1456138)

Wird das Programm schneller wenn die EXE kleiner ist - kann ich mir nicht vorstellen.

Das Programm an sich nicht, aber der Start des Programms, da weniger geladen werden muss. (Messbar nur mit mechanischen Festplatten, bei SSD ist es Wurst)

[Codehunter]

IMHO nehmen indirekt einkompilierte Binärresourcen einen nicht unerheblichen Teil der EXE ein. Grad wenn man externe Komponenten wie Devexpress verwendet. Ich habe mal einen Resourceneditor genommen und aus einer 30-MB-EXE alles rausgeworfen was nach Bitmap, AVI etc. aussah. Am Ende war sie noch 9 MB groß. Lief zwar nicht mehr gescheit, aber sowhat, Hauptsache die EXE war kleiner :-D

[noisy_master]

Um meine Exen kleiner zu bekommen nehme ich mpress.
Reduziert die Größe um mehr als die Hälfte UND : der Große Vorteil gegenüber UPX ist, dass bisher KEIN Virenscanner darauf angeschlagen hat

[Sherlock]

Exe Packer haben Nachteile, die nicht von der Hand zu weisen sind: Falsch positive durch Virenscanner mal außen vor, sorgen sie für eine ungünstige Arbeitsspeichernutzung. Und Arbeitsspeicher gibt es deutlich weniger als Plattenplatz. In diesem Thread wurde das bis zur totalen...äh... Abwendung vom Thema...mmmh, diskutiert: https://www.delphipraxis.net/192574-...oder-nein.html

Sherlock

[himitsu]

Zitat:

Zitat von Codehunter (Beitrag 1456147)

Grad wenn man externe Komponenten wie Devexpress verwendet.

Und dort dann auch noch standardmäßig alle Skins mit reingeladen werden, egal ob man die alle benutzt.

[hoika]

Hallo,
MadExcept verhindert schon mal das Komprimieren,
wohl, weil es da einen eigenen Memory-Manager gibt.

[NicoleWagner]

Danke allen für die Antworten!
und besonders dem Delphi-"Laien" für die sorgsame Liste.
Ich werden die Tips einmal von oben nach unten ausprobieren.
Insb. das ganz naheliegende mit "release" hatte ich nicht bedacht, da ich keine Verkaufssoftware erstelle.

Cheryll

[TiGü]

Zitat:

Zitat von NicoleWagner (Beitrag 1456160)

Insb. das ganz naheliegende mit "release" hatte ich nicht bedacht, da ich keine Verkaufssoftware erstelle.

Cheryll

Wieviel kleiner als 15 MB wurde es damit nun?
Hast du eine Zielgröße?

[Rolf Frei]

Am meisten mach das aus:

{$SetPEFlags IMAGE_FILE_RELOCS_STRIPPED}

Das muss im DPR platziert werden, am besten nach den uses und vor dem {$R *.res}.

Dein 15 MB bringst du aber wohl kaum unter 10-12 MB egal was du machst. Seit RTTI aktiviert ist, ist leider die Grösse der Exe's explodiert. Also als Alternative könntest du dein Projekt auf z.B. D7 "downgraden" und dann wäre es vermutlich nur noch um die 7-8 MB gross.

Was willst du aber damit erreichen?

[himitsu]

IMAGE_FILE_RELOCS_STRIPPED:

Und damit blockierst du gleich ein Sicherheitsfeature des Betriebssystems.
Dort werden (wenn aktiv) die DLLs/EXEn im RAM willkürlich verschoben, damit mit böse Häcker in ihren Viren/Trojanern/... nicht einfach mit statischen Adressen in fremdem RAM Programmcode umschreiben können, weil das Gewünschte dann ja jedes Mal wo anders liegt. (beliebt z.B. in Buffer Overflow Exploits)

Und für DLLs ist es auch noch fatal, wenn an dieser Adresse eine andere DLL oder die EXE bereits geladen ist und Windows somit deine DLL verschieben müsste, was es aber nicht mehr kann,
vor allem auch deswegen, weil kaum jemand die ImageBase definiert und 99,99% aller Delphi-DLLs und EXEn eigentlich auf der selben Adresse liegen. ($00400000)


Es gibt auch Progrämmchen und EXE-Packer, welche nachträglich diese Reallocation-Table entfernen.
(die ist dafür da, damit Windows beim Verschieben alle Zeiger im Code anpassen kann -> auf Prozeduren, Konstanten, Typen, globale Variablen, ...............)

[freimatz]

Zitat:

Zitat von Rolf Frei (Beitrag 1456188)

Also als Alternative könntest du dein Projekt auf z.B. D7 "downgraden" und dann wäre es vermutlich nur noch um die 7-8 MB gross.

Und da gäbe es noch den MASM. SCNR

[DevidEspenschied]

Zitat:

Zitat von noisy_master (Beitrag 1456148)

Um meine Exen kleiner zu bekommen nehme ich mpress.
Reduziert die Größe um mehr als die Hälfte UND : der Große Vorteil gegenüber UPX ist, dass bisher KEIN Virenscanner darauf angeschlagen hat

Ohne die alte Diskussion über UPX wieder rauskramen zu wollen, kannst du auf www.virustotal.com
mit ca 70 Virenschutzprogrammen Dein Kompilat testen, und meine hochgeladenen Dateien, auch wenn mit UPX gepackt, wurden noch nie bemängelt.

Trotzdem danke für den Tipp mit mpress, werde ich mir genauer anschauen.

[Rolf Frei]

Zitat:

Zitat von himitsu (Beitrag 1456191)

IMAGE_FILE_RELOCS_STRIPPED:

Und damit blockierst du gleich ein Sicherheitsfeature des Betriebssystems.
Dort werden (wenn aktiv) die DLLs/EXEn im RAM willkürlich verschoben, damit mit böse Häcker in ihren Viren/Trojanern/... nicht einfach mit statischen Adressen in fremdem RAM Programmcode umschreiben können, weil das Gewünschte dann ja jedes Mal wo anders liegt. (beliebt z.B. in Buffer Overflow Exploits)

Und für DLLs ist es auch noch fatal, wenn an dieser Adresse eine andere DLL oder die EXE bereits geladen ist und Windows somit deine DLL verschieben müsste, was es aber nicht mehr kann,
vor allem auch deswegen, weil kaum jemand die ImageBase definiert und 99,99% aller Delphi-DLLs und EXEn eigentlich auf der selben Adresse liegen. ($00400000))

Es geht hier aber um die Grösse einer EXE und nicht einer DLL. Von daher ist das problemlos nutzbar und bringt den grössten Erfolg. Wenn man die Doku zu diesem Flag liest, ist klar, dass man das bei einer DLL nicht nutzen sollte/darf.

[himitsu]

EXE und DLL ist das Selbe.


Und wenn man ExePacker nutzt, dann kann das Entfernen hier auch mal zu problemen führen. (wenn zufällig der PackerCode an der selben Stelle geladen wird und er dann die EXE nicht auf seine Stelle bekommt, oder diese Stelle durch was Anderes belegt ist, wie z.B. eine DLL, welche global in alle Anwendungen injiziert wird)

[DieDolly]

Über Größen von Exedateien sollte sich heute keiner mehr Gedanken machen. Selbst wer nur 1 GB Arbeitsspeicher hat, bekommt keine Probleme ob die Exe nun 10 MB oder 5 MB groß ist.

Das ist alles Jammern auf hohem Niveau, mehr nicht.
Was man aber definitiv machen sollte ist, auf Release umzustellen.

[himitsu]

Klar ... keine Gedanken ... aber wenn man 0,7 MB (einstellige Delphiversionen) mit Richtung 20 MB aktuelle Version für eine nichtstuende Anwendung betrachtet, dann ist es dennoch nicht ganz OK.

In Richtung Mobile mit keinerem Speicher im Handy geht es aber auch heute wieder los
und auch wenn man schonmal in Richtung MiniPCs ala Raspberry (auch wenn Delphi das wohl nie können wird) oder SmartWatch lunscht.

[DieDolly]

Eine frische Anwendung erstellt mit 10.3.3 (Debug) hat bei mir 12 MB. Release 2.3 :stupid:

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1456226)

Klar ... keine Gedanken ... aber wenn man 0,7 MB (einstellige Delphiversionen) mit Richtung 20 MB aktuelle Version für eine nichtstuende Anwendung betrachtet, dann ist es dennoch nicht ganz OK.

Beim Umsteig von D6 auf XE6 ist unserer Hauptanwendung von 18 auf 24 MB gewachsen.
Der später Umstieg von XE6 auf 10.2 war praktisch nicht mehr relevant.
Was aber relevant war, waren die Produktivitätszuwächse (Sprachfeatures, Höhere IDE-Stabilität, Besseres Debugging) und die Reduzierung der Problem durch den Compiler (Abstürze D6 mit Multisockel-Systemen)

Zitat:

Zitat von himitsu (Beitrag 1456226)

In Richtung Mobile mit keinerem Speicher im Handy geht es aber auch heute wieder los

Eigentlich ist die Zeit schon wieder vorbei. Vor 5 Jahren war es noch ein relevantes Thema. Heut bekommt man Speicher selbst bei den Einstiegsgeräten "nachgeschmissen".
Heute zählt Funktionalität. Ob die Anwendung nun 5 oder 20 MB benötigt - Interessiert doch keinen mehr.

[himitsu]

Och, bei 64GB oder 32GB mit MultiUser im Android, da ist schnell sowas von voll.

[Sherlock]

Zitat:

Zitat von himitsu (Beitrag 1456231)

Och, bei 64GB oder 32GB mit MultiUser im Android, da ist schnell sowas von voll.

Da nutzt aber auch kein UPX :lol: Ich befürchte, für die "exotischen" OSe, die Delphi anvisiert, werden wir noch lange auf eine optimierte Dateigröße warten dürfen...sofern es keine Forderungen durch die jeweiligen OS-Hersteller gibt.

Sherlock

[TurboMagic]

Ja, die bisherigen Maßnahmen in dem Bereich waren mehrheitlich eher kosmetischer Natur.

[Rolf Frei]

Zitat:

Zitat von himitsu (Beitrag 1456223)

EXE und DLL ist das Selbe.

Ehm, nein ist es nicht. Eine Exe muss nicht "reallocated" werden, eine DLL hingegen schon, wenn alle die gleiche Base-Adresse haben. Google mal danach.

Zitat:

IMAGE_FILE_RELOCS_STRIPPED removes the relocation (".reloc") section from Win32 PE EXE files, reducing their size. Most compilers/linkers (including Delphi) put a relocation section in EXE files, but this is actually not necessary since EXEs never get relocated. Hence, a relocation section only wastes space.

[Stevie]

Interessant, dass bei diesen "Exe Größe" Diskussionen meist komplett vergessen wird, das selbst die modernsten Prozessoren keinen duzende MB großen Instruction Cache haben. Das heißt, je größer und verteilter der ausgeführte Code, desto eher wird der CPU Durchsatz vom RAM gebremst.

Aber ja, wir reden hier von High Performance und weniger von nem GUI Progrämmchen wo das kaum Auswirkungen hat.

[himitsu]

Zitat:

Zitat von Stevie (Beitrag 1456276)

das selbst die modernsten Prozessoren keinen duzende MB großen Instruction Cache haben. Das heißt,

Da bin ich selber mal drauf reingefallen.

Hatte einen Code schön mit Assembler "optimiert", mit dem Ergebnis, dass auf modernen CPUs (die arbeiten teilweise schon den/die nächsten Befehl vor)
alles extrem langsamer lief, im Gegensatz zu dem was der Delphi-Compiler produzierte.
Durch ein paar Jumps wurde dieser Cache und das "umsonst" Vorgearbeitete ständig verworfen und an anderer Stelle wieder neu angefangen. :oops:

Zitat:

Zitat von Rolf Frei (Beitrag 1456263)

Ehm, nein ist es nicht.

Doch.
https://de.wikipedia.org/wiki/Addres..._Randomization

[freimatz]

Also ich versuche ja meine Programme so zu machen, dass sie den Bedürfnissen der Anwendern möglichst entspricht.
Die Grösse der Exe war in den vielen Jahren bislang nur einmal ein Thema. Und das war auch nicht bei einem Anwender sondern einem Herausgeber der meinte, er könne zu dem Buch nur zwei Disketten beilegen. :wink:
Aber jedem sein Hobby wie es ihm gefällt.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1456277)

Hatte einen Code schön mit Assembler "optimiert", mit dem Ergebnis, dass auf modernen CPUs (die arbeiten teilweise schon den/die nächsten Befehl vor)
alles extrem langsamer lief, im Gegensatz zu dem was der Delphi-Compiler produzierte.
Durch ein paar Jumps wurde dieser Cache und das "umsonst" Vorgearbeitete ständig verworfen und an anderer Stelle wieder neu angefangen. :oops:

Was du beschreibst, klingt weniger nach einem Problem mit der Instruction Cache Größe sondern nach einem Pipeline Stall, durch z.B. Register Pressure oder Branch Mispredictions.
Kann aber auch durchaus daran liegen, dass besonders oft ausgeführter Code ungünstig über mehrer Cachelines lag.

[Codehunter]

Ich habe solche Diskussionen mit Kollegen auch schon mehrfach geführt. Weniger bzgl. der Dateigröße von EXEn, aber was die Belegung von Arbeitsspeicher betrifft. Die Problemstellungen mögen bei uns sehr spezifisch sein, das Paradigma denke ich ist allgemeingültig:

Wenn man die Wahl hat zwischen hoch optimiertem Code oder einfach großen Caches im RAM, dann programiere ich bevorzugt RAM-lastig. Ganz einfach deshalb, weil es sehr zeitintensiv auf unserer Seite ist, hoch optimierten Code zu schreiben und zu pflegen. Dagegen ist Arbeitsspeicher zu kaufen und einzubauen inzwischen beinahe die lächerlich kleinste Übung. Was immer machbar ist, wird in irgendwelchen Listen (bevorzugt TDictionary oder Virtual Treeview) geparkt. Dateioperationen nur wenns unbedingt sein muss und dann per TStream angeströmt.

Wobei ich mich hierbei nur auf VCL beziehe. Bei FMX und mobilen Targets sehen die Anforderungen schon ganz anders aus.

[Delphi-Laie]

Zitat:

Zitat von noisy_master (Beitrag 1456148)

Um meine Exen kleiner zu bekommen nehme ich mpress.
Reduziert die Größe um mehr als die Hälfte UND : der Große Vorteil gegenüber UPX ist, dass bisher KEIN Virenscanner darauf angeschlagen hat

Komprimiert aber nicht so stark wie UPX, jedenfalls nach meiner Wahrnehmung.

[himitsu]

G. sagt, dass durch mpress auch schon der Eine oder Andere von seinem Virenscanner genervt wurde (False-Positive)
und mit größerer Verbreitung von mpress würde bestimmt auch öfters mal ein Scanner ansprechen.

Bei UPX raucht es oft, weil viele eine modifizierte Variante nutzen, die das direkte Entpacken verhindern sollten,
oder wo mit schwindligen Einstellungen die Datei noch kleiner gemacht wurde.
Aber hier haben bereits ein paar AntiVirenSoftwaren einen Entpacker für bekannte EXEPacker integriert, damit der Inhalt vor Programmstart geprüft werden kann,
aber wenn das Entpacken aus sonstwelchen Gründen nicht geht, dann wird dem Programm schnell per se etwas Böses unterstellt.

Und bei AntivirenProgrammen ohne Entpacker, aber auch bei denen Mit, landet auch oft sehr gern mal die Signatur des Packers im Virenverzeichnis, weil dessen Signatur natürlich das einzige Markante ist, und da viele böse Entwickler ihre Viren auch gern möglichst klein machen, kommt sowas öfters mit auf die Listen. :stupid:

[Codehunter]

Lassen sich "geUPXte" EXEn eigentlich signieren? Also nach dem Packen mit UPX meine ich. Würde das einen Unterschied machen in Bezug auf die Scanner?

[Dalai]

@Codehunter:
Ja, das geht wohl. Die EXE vom Total Commander war in Version 7.0 mit UPX gepackt und außerdem digital signiert, seit Version 7.50 ist sie nur noch signiert.

Grüße
Dalai

[himitsu]

Die Signierung bezieht sich ja auf den Dateiinhalt.
Signieren und dann Packen geht nicht gut,
aber auf das gepackte Ergebnis passt es drauf.


Den Dateiinhalt zu signieren, nachdem er geladen wurde, also nachdem dessen Daten umgeschrieben wurden, mit den angepassten Adressen, wäre etwas zu umständlich. (einen Hash über etwas bilden, was sich ständig verändert).
Wenn, die Signierung so arbeiten täte, dann müsste vor dem Packen signiert werden.