Wie bekomme ich die exe kleiner?

[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.