UPX-Packer ja oder nein?

[bra]

Ich habe das mal mit unserer Anwendung getestet und da ist der Unterschied deutlich zu sehen:


Ungepackt (exe 47 MB)
Max. Arbeitssatz (Speicher): 104.468K
Arbeitsspeicher (privater Arbeitssatz): 61.520K

Mit UPX gepackt (exe 18 MB)
Max. Arbeitssatz (Speicher): 137.900K
Arbeitsspeicher (privater Arbeitssatz): : 107.880K

[a.def]

Also ist da doch ein Unterschied was den Arbeitsspeicher angeht welcher nicht vernachlässigbar ist.

[nahpets]

Interessant, da scheint es ja dann auch Abhängigkeiten von Programm zu Programm geben.

Bei meinen Programmen ist mir sowas bisher noch nicht aufgefallen, allerdings nutze ich UPX auch nicht mehr wirklich.

Es war interessant, als USB-Sticks noch nicht im GB-Bereich waren und vor allem zu Zeiten, als Disketten durchaus noch ein üblicher Datenträger für Rettungssysteme waren.

Aber das passt dann wohl doch besser zu diesem Thema: http://www.delphipraxis.net/192506-m...wird-wenn.html

[Uwe Raabe]

Zitat von a.def:

Also ist da doch ein Unterschied was den Arbeitsspeicher angeht welcher nicht vernachlässigbar ist.

Diese Frage bei StackOverflow gibt, trotz immer noch fehlender Antworten, einen Einblick in die dahinter steckende Komplexität: Size of exe file vs available memory

Demnach müsste der Effekt z.B. schon unterschiedlich sein, je nachdem ob Debug-Info in der EXE enthalten ist oder nicht.

[himitsu]

EXE/DLL/BPL sind standardmäßig als MMF mit CopyOnWrite in den Arbeitsspeicher gemapt. (jede der benötigten PE-Sectionen hintereinander)

Sie können also ausgelagert werden und belegen im Prozess nur den virtuellen Speicher, aber im realen Speicher sind sie vernachlässigbar.
Erst wenn ein Prozess an den gemapten Daten im RAM was ändert, bekommt er für jeweils den umgebenen 4KB-Block eine eigene Kopie.

Außerdem können mehrere Prozesse den selben "realen" Speicher verwenden, wenn sie Teile des gleichen Images verwenden.
Stell dir mal vor jeder der 10000 aktiven Prozesse müsste seine eigenen Kopieen der System-DLLs in den Speicher laden.
Bei nur 1000 Prozessen wären das alleine 1,5 GB für die ntdll.dll .

[jaenicke]

Zitat von himitsu:

Außerdem können mehrere Prozesse den selben "realen" Speicher verwenden, wenn sie Teile des gleichen Images verwenden.

Und wenn die Exe bzw. DLL nicht mit UPX gepackt ist. Ansonsten würde jedesmal ein neuer Speicherbereich reserviert werden...

[himitsu]

Jupp, UND.

Bei UPX wird der Speicher vom Loader reserviert, beschrieben und Windows weiß nichts davon, selbst wenn ein anderes Programm das gleiche macht.
Sowas wie UPX könnte man ja nicht nur auf die EXE, sondern auch auf DLLs anwenden.

[EWeiss]

Wenn der Entwickler von Delphi in der Lage wäre vernünftige Kompilate zu erstellen bräuchte man so etwas, UPX oder vergleichbare Packer überhaupt nicht.
Das man unnötige Dinge in einer EXE komprimieren bzw. erst gar nicht einbinden muss beweisen unter anderem ResourceHacker und UPX.

Der gleiche Code in D6 und letztendlich Kompiliert mit der letzten Delphi Version sind vom Größen Unterschied schon beträchtlich.
Aber gut das hatten wir im anderen Thread schon diskutiert.

[IronieOn]Aber wir wissen ja alle Delphi ist perfekt. LOL.[/IronieOff]

gruss

[himitsu]

Komisch, wenn ich UPX auf ein perfektes C++-Kompilat los lasse, dann wird das auch Kleiner.

Gut, .NET und VisualBasic-Programme sind ja auch viel kleiner. (wenn man die Laufzeitbibliotheken ignoriert)

[jaenicke]

Zitat von EWeiss:

Wenn der Entwickler von Delphi in der Lage wäre vernünftige Kompilate zu erstellen bräuchte man so etwas, UPX oder vergleichbare Packer überhaupt nicht.
Das man unnötige Dinge in einer EXE komprimieren bzw. erst gar nicht einbinden muss beweisen unter anderem ResourceHacker und UPX.

Das widerspricht aber eben der Funktionsweise von Windows. Unter Windows werden DLLs von Windows automatisch in Speicherbereiche der Exen, die sie laden, eingeblendet, damit sie nicht mehrfach im Speicher liegen müssen, so wie himitsu schon geschrieben hat. Wenn Delphi selbst das durch Komprimieren umgehen würde, wäre das ein Nogo, weil das den Arbeitsspeicher vollmüllen würde sobald eine solche Anwendung mehrfach läuft usw.

Zudem ist es eben auch hoch bedenklich, wenn eine Anwendung Speicher schreibt und den dann ausführbar macht. Es ist schon absolut korrekt, wenn solche Anwendungen erst einmal verdächtig sind.

Vernünftig hat jedenfalls nichts mit ultraklein zu tun, weil das für 99% der Fälle nicht relevant ist. Und unnötig sind die Daten ja nicht, die werden ja durchaus verwendet. Nur eben nicht durch jeden.
Deshalb wäre es durchaus wünschenswert, wenn man die RTTI Informationen z.B. komplett herauslassen könnte usw.
Wenn dann die Anwendung auch nicht mehr wie gewünscht funktioniert, wäre das ja egal, weil das ja durch den Entwickler so eingestellt wurde.
Aber ob das wirklich wichtiger als Bugfixes und neue Features ist... sehe ich zumindest nicht so.