Delphi-PRAXiS - Lazarus, EXE groß

Seite 2 von 3

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)

- Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)

- - Lazarus, EXE groß (https://www.delphipraxis.net/170853-lazarus-exe-gross.html)

AW: Lazarus, EXE groß

Ich lese immer wieder, dass mit UPX argumentiert wird. Für was soll das gut sein? Der Start dauert erheblich länger und im Speicher ist die EXE genauso groß wie ohne UPX. Völlige Augenwischerei!

AW: Lazarus, EXE groß

Zitat:

Zitat von Insider2004 (Beitrag 1186010)

Ich lese immer wieder, dass mit UPX argumentiert wird. Für was soll das gut sein? Der Start dauert erheblich länger und im Speicher ist die EXE genauso groß wie ohne UPX. Völlige Augenwischerei!

Und noch mehr:

Are there any downsides to using UPX to compress a Windows executable?

AW: Lazarus, EXE groß

Zitat:

Zitat von Insider2004 (Beitrag 1186010)

Ich lese immer wieder, dass mit UPX argumentiert wird. Für was soll das gut sein? Der Start dauert erheblich länger und im Speicher ist die EXE genauso groß wie ohne UPX.

Sogar größer, denn der Dekomprimierungscode wandert ja mit in den Haupt-/Arbeitsspeicher (er muß dort mit hinwandern).

Zitat:

Zitat von Insider2004 (Beitrag 1186010)

Völlige Augenwischerei!

Genaugenommen schon. Wenn man es auf der Festplatte oder zur Übertragung verkleinern möchte, gibt es viel bessere Komprimationsmöglichkeiten.

AW: Lazarus, EXE groß

Diese Diskussion um die Größe von Programmen, die eigentlich nichts oder nichts Sinnvolles machen, kommt offenbar immer wieder hoch. Worauf es doch wirklich ankommt ist die Größe von real genutzten Programmen und die durch deren Größe real existierenden Nachteile (wenn es denn welche gibt). In dem Fall kann man dann wirklich um Maßnahmen zur Größenreduzierung nachdenken und entscheiden, ob deren Nachteile das aufwiegen bzw. der ganze Aufwand wirklich lohnt. Als Argument für die Entscheidung über eine Entwicklungsumgebung (zumindest im Desktop-Bereich) taugt das allerdings in keinem Fall.

Zu den oft angeführten "leeren" Programmen fällt mir folgendes ein:

Es gibt ein Äquivalent zu einem solchen Programm das nichts macht, das dabei aber unendlich schnell ist, sich automatisch beliebig oft startet, den Prozessor überhaupt nicht belastet, garantiert fehlerfrei und mehrbenutzerfähig ist, vom Benutzer nicht wahrgenommen wird, von keinem Virenscanner angemeckert wird, unter jedem Betriebssystem läuft, auf jedem Rechner vorinstalliert ist und dabei genau 0 Bytes groß ist.

AW: Lazarus, EXE groß

Ist das wirklich so sinnlos?

Ist die Größe einer Exe-Datei, der ein "leerer" Quelltext zugrundeliegt, nicht ein Grad-, ja Gütemesser, wie es um die Größe "sinnvoller" Compilate bestellt ist? Nach meiner Erfahrung schon!

AW: Lazarus, EXE groß

Zitat:

Zitat von Delphi-Laie (Beitrag 1186014)

Humbug, dazu gibt es doch ganz andere Kriterien. Sonst wuerdest du ja auch nicht Delphi benutzen sondern C, wie der TE vorschlaegt.
Viel wichtiger als die paar Bytes sind in heutigen Zeiten doch Abstraktion, Portabilitaet und Interopabilitaet (und natuerlich schoener, gut schreib- und lesbarer Code).

AW: Lazarus, EXE groß

Zitat:

Zitat von implementation (Beitrag 1186016)

Zitat:

Zitat von Delphi-Laie (Beitrag 1186014)

Humbug, dazu gibt es doch ganz andere Kriterien.

Die Titulierung meiner erfahrungsbasierten Aussage als "Humbug" ist keine sachliche Auseinandersetzung mit meiner Aussage.

Zitat:

Zitat von implementation (Beitrag 1186016)

Sonst wuerdest du ja auch nicht Delphi benutzen sondern C, wie der TE vorschlaegt.

Was hat den "C" auf einmal damit zu tun? Würfe jetzt noch jemand reinen Assembler ein - der erzeugt erstmal kleine Exe-Dateien!

AW: Lazarus, EXE groß

Zitat:

Zitat von Delphi-Laie (Beitrag 1186022)

Würfe jetzt noch jemand reinen Assembler ein - der erzeugt erstmal kleine Exe-Dateien!

Hatte ich schon:

http://www.delphipraxis.net/1185991-post7.html

AW: Lazarus, EXE groß

Natürlich ist die Größe einer "leeren" EXE keine Aussage, was eine volle EXE später mal für eine Güte haben könnte.

Nur ein paar Beispiele:

- Die Anfangsgröße sagt nichts aus, wie es später mal wird.
> Wenn ich mit einer kleinen EXE anfange, aber pro Zeile Code kommt ganz viel dazu, dann kann es am Ende auch ganz Groß werden.
> Wenn ich mit einer rißigen EXE anfange, aber pro Zeile Code kommt nur wenig dazu, dann kann es am Ende auch kleiner werden.

- Die Größe der EXE sagt absolut nichts darüber aus, wie gut und sicher der darin enthaltene Code ist.
> Ich kann mit viel Code ganau viel Schrott produzieren, wie mit wenig Code.

Und das Wichtigste:

- Ein großer Code kann sicherer sein ... hauptsache er ist einfach und vorallem wartbar.

- Wenn man einen Code ganz klein und superschnell bekommt, dann kann es toll sein.
Aber wenn ich dann am Ende nur noch hochoptimierten Assemblercode hab, den kein Mensch jemals wieder verstehen kann und in dem man auch nie wieder was ändern könnte, dann bringt das einem nicht unbedingt sehr viel.

Und dann eben noch die Sache mit den Laufzeitbibliotheken:
Man kann eben nicht alles direkt mit vergleichen.
z.B. ein Delphi-Programm wo alles gleich drin ist,
oder ein ganz kleines Delphiprogramm, welches gegen Runtimebibliotheken gelinkt wurde, die man mitgeben müßte.
(ja, man kann sämtlichen Code in BPLs auslagern und hätte dann eine EXE, mit der Funktionalität eines kompletten MS Office, welche aber nichtmal 100 KB groß ist)
oder eben ein .NET-Programm, wo man auch noch ein rießiges Framewörk im Hintergrund braucht.
Aber die besten Beispiele sind Basic, PHP, JavaScript, wo nur eine winzige Textdatei nötig ist, man aber zusätzlich, wie beim .NET, ein "rießiges" Framework/Interpreter benötigt.

Wer wirklich nur auf die Dateigröße achtet, der sollte direkt mit Assembler anfangen.
siehe die geilen 64K-Programme

Nja, was man von sowas wie UPX halten kann, kann man hier im Forum auch schon öfters nachlesen.
Nein, für kleine Tools, welche nicht installiert werden, mag es manchmal OK sein, aber oftmals ist es eigentlich garnicht nötig, daß man auch noch das letzte Byte mit sonstwelchen windigen Tricks einspart.
PS: Bei Delphi und Lazarus kann man auch noch so Einiges einsparen, wenn man gewisse Resourcen und Realocationstabellen rausschmeißt.

AW: Lazarus, EXE groß

Zitat:

Zitat von JamesTKirk (Beitrag 1186002)

Die Option heißt aber nicht "ohne Debug-Infos". Die Option heißt "Debug Informationen generieren" und greift nur auf das aktuelle Projekt, nicht aber auf die verwendeten Packages. Und hier ist die LCL das Package, welches den ganzen Wust an Debug Informationen mitbringt. "-Xs" sorgt dann einfach nur dafür, dass ganz einfach gar keine Debug Informationen (von welcher Unit sie auch kommen) eingebunden werden.

Da halte ich den Delphi-Weg für sinnvoller. Packages (VCL/CLX/...) sind ohne Debug-Infos und wenn man mal gegen die mitgelieferten Sourcen Debuggen will setzt man den Haken "Mit Debug-DCU's kompilieren".

Seite 2 von 3