Warum PE-Packer sehr fragwürdig sind ...

[Phoenix]

Also als Sinnlos würde ich die echt nicht bezeichnen.

Beispiel: Eine .exe liegt (komprimiert) auf einem Fileserver für den zentralen Zugriff für Clients in der Größenordnung von mindestens 50 Stück.

Das macht in Deinem Beispiel morgens früh wenn alle darauf zugreifen 50 * 0,7 MB = 35 Mb Netzwerkverkehr weniger. In unserer damaligen Produktivumgebung beim Kunden war die unkrompimierte .exe allerdings knapp 20 MB gross und die gepackte nur 4,5. Ergo: 775 MB weniger Daten zu schaufeln. Das macht morgens früh schon einiges aus - zumal ja auch noch anderer Netzwerkverkehr wie Datenbankzugriffe etc. pp. dort laufen.

Im übrigen war die komprimierung der .exen zwingend notwendig. Dank des bescheidenen opportunistic locking des Windows NT 4 Servers kam es bei mehrfachen zeitgleichen Zugriffen auf eine Datei unter Umständen dazu, das die Datei sogar für weitere lesezugriffe gesperrt wurde, weswegen dann viele Clients morgens auf das Timeout warten mussten um eine Fehlermeldung zu erhalten und es dann nochmal probieren durften.

Eine 4,5 MB Datei ist deutlichst schneller gelesen (und wieder entsperrt) als eine 20 MB - Datei.

Letzten endes war durch den Exe-Packer in dem Fall ein deutlicher Effizienzgewinn bei der Arbeit zu erzielen. Also keine Rede von 'Sinnlos'.

Ich gebe zu dies ist kein Fall der bei jedem alltäglich vorkommt. Aber es gibt eben auch für Exe-Packer Anwendungsbereiche die deutlichst Sinn machen.

[bigg]

durchschn. Zugriffszeit eines Speicherriegels: 1,6 - 60 ns
durchschn. Zugriffszeit einer Festplatte: 3 - 12 ms


Nun sollte auch klar sein, welche Anwendung schneller lädt.
Die gepackte oder die ungepackte Version? :gruebel:



@olli:
Dann verzichtetst du also auch auf andere Kompressionsverfahren?
MP3, DIVX, JPEG ?

[Olli]

Zitat:

Zitat von jfheins

Olli, du als ISDN-Nutzer kannst es dir sicher vorstellen:

56k-Modem. ISDN kommt frühestens im September (Danke T-Com!) und auch dann laufe ich weiterhin mit dem Analogmodem.

Zitat:

Zitat von jfheins

Ohne Exe-Packer:
Du ziehst dir ein 4 MB Programm aus dem Netz und führst es aus, vielleicht werden dann auch nur 3 MB geladen.

Mit:
Du ziehst dir 1 MB, und dafür wird 0,2% des Arbeitsspeichers mit dem Exe-Packer "zugemüllt" und ausserdem 1 MB zuviel entpackt.

Im Vergleich sind es 2 MB zuviel.

1. 4 MB, davon 3 geladen ... und ungepackt -> 3 MB
2. 1 MB + 4 MB vom Entpacken -> 5 MB

Zitat:

Zitat von jfheins

Es werden im Endeffekt vielleicht 0,4% des Arbeitsspeichers unnötig verbraucht - ein verschwindend geringer Nachteil im Vergleich zur Dateigröße.

Das muß jeder für sich entscheiden, ob das für ihn viel ist. IMO ist es das. Da beipielsweise eine VM im Gegensatz zu einem normalen Programm echten Speicher (weil im K-Mode) anfordert, ist jedes MB für mich wichtig. Da kann ich mir nicht einfach 2 MB leisten, die einfach verschwendet werden. Abgesehen davon halte ich Leute, die ihre Programme ungepackt ins Netz stellen (ob nun als Installer oder als RAR, 7Z, ZIP, GZ oder sonstwas gepackt ... mach keinen Unterschied) für doof. Also lade ich deren Programme nicht runter. Und wenn dein EXE-Packer die 5-MB-EXE auf 1 MB schrumpft, schafft der 7z-Packer zB 0,7 oder noch weniger. Also habe ich wieder alle Vorteile und keinen Nachteil (außer dem einmaligen Entpacken).

Zitat:

Zitat von jfheins

Und für dlls, die nur von einem Programm (oder 2) verwendet werden, halte ich dieses Verfahren ebenfalls für annehmbar.

Ich stelle mir gerade vor, wie aussähst, wenn die Toolbar-Hersteller genauso dächten (angenommen du arbeitest mit dem IE). Dort laufen nämlich oft mehrere Instanzen ... und bei COM-Objekten in gepackten DLLs nimmt das Chaos seinen Lauf. :lol:

Zitat:

Zitat von jfheins

Exe-Packer können übrigens deutlich effektiver sein, als z.B. .zip o.ä. ;) Ausserdem könnnen sie von jedem (mit Windows) geöffnet werden, was bei -rar nicht der Fall ist ...

Das das klassische ZIP nicht mehr auf der Höhe der Zeit ist, mag sein. Mir ist jedoch bei den modernen Packformaten kein Beispiel bekannt, welches du hier anführst.

[phXql]

Zitat:

Zitat von jfheins

Exe-Packer können übrigens deutlich effektiver sein, als z.B. .zip o.ä. ;) Ausserdem könnnen sie von jedem (mit Windows) geöffnet werden, was bei -rar nicht der Fall ist ...

dann nimm 7z und mach ein SFX-Archiv draus...

abgesehen davon versagt mein UPX irgendwie bei .NET-Assemblies ;)

[jfheins]

Zitat:

Zitat von Oliver

Mir ist jedoch bei den modernen Packformaten kein Beispiel bekannt, welches du hier anführst.

Zitat:

Zitat von phXql

dann nimm 7z und mach ein SFX-Archiv draus...

Sorry, in diesem Punkt hab' mich vertan, siehe Edit oben ... :oops:

[Olli]

@Phoenix: Ungepackter Transfer übers Netz und schlechte Fileserver würde ich ungern als Argument für eine Sache gelten lassen, welche permanent einen Nachteil bringt. Hier könnte allein ein transparentes Kompressionsverfahren während der Übertragung Abhilfe schaffen.

Zitat:

Zitat von Phoenix

Eine 4,5 MB Datei ist deutlichst schneller gelesen (und wieder entsperrt) als eine 20 MB - Datei.

Jupp.

Zitat:

Zitat von Phoenix

Letzten endes war durch den Exe-Packer in dem Fall ein deutlicher Effizienzgewinn bei der Arbeit zu erzielen. Also keine Rede von 'Sinnlos'.

Spätestens bei DLLs sind sie sinnlos.

Zitat:

Zitat von bigg

Nun sollte auch klar sein, welche Anwendung schneller lädt.
Die gepackte oder die ungepackte Version? :gruebel:

Dank fehlenden Nachteils dürfte NTFS-Komprimierung hier schneller und besser sein als ungepackt.

Zitat:

Zitat von bigg

Dann verzichtetst du also auch auf andere Kompressionsverfahren?
MP3, DIVX, JPEG ?

Nein ... ich weiß aber auch nicht so recht, wie du auf die Idee kommst verlustbehaftete Kompressionsverfahren mit einem EXE-Packer zu vergleichen. Nur weil eine BMP RLE-kodiert ist, ist sie ja nicht gleich schlecht. Aber bei RLE, oder auch NTFS-Kompression sind Kompressionsrate und CPU-Last gut ausbalanciert.

Ach übrigens, wenn dank der Speicherverschwendung mit EXE-Packern das Speicherauslagern beginnt, dann hat euch das System aber einen Strich durch eure 12ns-Rechnung gemacht!

[bigg]

Zitat:

dann nimm 7z und mach ein SFX-Archiv draus...

Nur komprimiert 7Zip nicht effektiver als UPX.
Wenn doch, poste eine Beispielanwendung.

PS: 7Zip benötigt min. 36 MB zum Entpacken bei höchster Stufe.

[Robert_G]

Zitat:

Zitat von Phoenix

die unkrompimierte .exe allerdings knapp 20 MB gross

20MB? :shock:
Wäre es nicht schon 18MB früher an der Zeit gewesen, alles mögleich an Klassen in Packages auszulagern?
So hätten morgens nur Packages mit neuerer Revision gesaugt werden müssen... (Welches sich wohl meistens auf 0MB oder ein paar KB belaufen hätte...)
Kann ich irgendwie nicht als Vorteil von ExePackern sehen, eher als ineffiziente Herangehensweise... ;)

[phXql]

Zitat:

Zitat von jfheins

Zitat:

Zitat von Oliver

Mir ist jedoch bei den modernen Packformaten kein Beispiel bekannt, welches du hier anführst.

Zitat:

Zitat von phXql

dann nimm 7z und mach ein SFX-Archiv draus...

Sorry, in diesem Punkt hab' mich vertan, siehe Edit oben ... :oops:

wenn du ein SFX-Archiv machst, dann können sie doch von jedem geöffnet werden...

[Olli]

Zitat:

Zitat von bigg

Nur komprimiert 7Zip nicht effektiver als UPX.
Wenn doch, poste eine Beispielanwendung.

:shock: was für ein Quatsch.

Abgesehen davon, daß ich "--force" benutzen mußte um UPX überhaupt zu überzeugen, komme ich bei UPX und WinDirStat 1.1.2 (Unicode) einer normalen Allerweltsanwendung auf einen Unterschied von etwa 270kB!

Zitat:

Zitat von bigg

PS: 7Zip benötigt min. 36 MB zum Entpacken bei höchster Stufe.

Und das auch nur einmal nach dem Transport.

@phXql: Das war ja gerade die Anforderung ;)