Lazarus, EXE groß

[Lyan]

Hallo,

wie kommt es, dass trotz richtiger Compilereinstellungen (Linker) eine leere ConsoleAPP

Delphi-Quellcode:

program project1;

begin

end.

eien Filesize von 55kb hat? Das geht mir nicht in den Kopf, unter C sinds 6kb.

[himitsu]

Hast du mal die Debuginfos abgeschaltet?


In Delphi (XE3):

Delphi-Quellcode:

program Project11;

{$APPTYPE CONSOLE}

begin

end.

Debug: 160 KB
Release: 21 KB

Aber ganz im Ernst ... wen interessieren schon die paar Bytes.

[Uwe Raabe]

Zitat:

Zitat von Lyan (Beitrag 1185975)

unter C sinds 6kb.

Aber mit wahrscheinlich 100x sovielen Buffer Overruns...

[ThomasBab]

Hallo!

Hier http://wiki.lazarus.freepascal.org/Size_Matters/de gibt es eine Info dazu.

[Lyan]

Folgende Anwendung:

Delphi-Quellcode:

unit Unit1;

interface

uses
  Classes, SysUtils, Forms, Controls, Graphics, Dialogs;

type

  { TForm1 }

  TForm1 = class(TForm)
    procedure FormCreate(Sender: TObject);
  private
    { private declarations }
  public
    { public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.lfm}

procedure TForm1.FormCreate(Sender: TObject);
begin
  showmessage('64-Bit');
end;

end.

hat... 13,9 MB!!!! (Mit Smartlinken und ohne debug infos)!

Naja Lazarus erstmal deinstallieren. Mir ging es nur um 64-Bit, aber dann ists mir egal, dann lieber Delphi 7 und dafür 14kb (9kb mit upx).

[himitsu]

Also der Vergleich mit Delphi 7 ist auch nicht ganz fair.

Delphi-VCL + Win64 + klein bissl Code:
12,1 MB = Debug-Build
3,3 MB = Release-Build
2,7 MB = Release-Build + RTTI deaktiviert

[Uwe Raabe]

Zitat:

Zitat von Lyan (Beitrag 1185989)

dann lieber Delphi 7 und dafür 14kb (9kb mit upx).

Warum dann nicht gleich handoptimierter Assembler-Code?

[JamesTKirk]

Zitat:

Zitat von Lyan (Beitrag 1185975)

Hallo,

wie kommt es, dass trotz richtiger Compilereinstellungen (Linker) eine leere ConsoleAPP

Delphi-Quellcode:

program project1;

begin

end.

eien Filesize von 55kb hat? Das geht mir nicht in den Kopf, unter C sinds 6kb.

Du bist dir bewusst, dass du hier Äpfel mit Birnen vergleichst? Unter C hast du die ganze Runtime in DLLs (oder das entsprechende Äquivalent unter anderen Betriebssystemen) und in Delphi/Free Pascal hast du die Runtime in der Anwendung drin. Link mal dein C Programm statisch und dann vergleich mal die Größen. Das ist dann um einiges fairer.

Zitat:

Zitat von Lyan (Beitrag 1185989)

Folgende Anwendung:

(snip)

hat... 13,9 MB!!!! (Mit Smartlinken und ohne debug infos)!

Naja Lazarus erstmal deinstallieren. Mir ging es nur um 64-Bit, aber dann ists mir egal, dann lieber Delphi 7 und dafür 14kb (9kb mit upx).

Du musst noch "Debugger Informationen aus der ausführbaren Datei entfernen (-Xs)" aktivieren, dann kommst du auf circa 3 MB. Allzu viel kleiner geht nicht, da die LCL ja die darunterliegende Plattform abstrahieren muss ( => zusätzlicher Code). Aber die Größe steigt dann nur noch leicht an, wenn du weiteren Code/weitere Formulare hinzufügst.

Gruß,
Sven

[Bernhard Geyer]

Zitat:

Zitat von JamesTKirk (Beitrag 1185994)

Du musst noch "Debugger Informationen aus der ausführbaren Datei entfernen (-Xs)" aktivieren, dann kommst du auf circa 3 MB. ...

Ich glaube diesen Fehler machen viele Lazarus-Anfänger. Wieso kann man diese Option nicht automatisch an die Option "Ohne Debug-Infos" binden?

[JamesTKirk]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1185995)

Zitat:

Zitat von JamesTKirk (Beitrag 1185994)

Du musst noch "Debugger Informationen aus der ausführbaren Datei entfernen (-Xs)" aktivieren, dann kommst du auf circa 3 MB. ...

Ich glaube diesen Fehler machen viele Lazarus-Anfänger. Wieso kann man diese Option nicht automatisch an die Option "Ohne Debug-Infos" binden?

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.

Gruß,
Sven

[Insider2004]

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!

[Uwe Raabe]

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?

[Delphi-Laie]

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.

[Uwe Raabe]

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.

[Delphi-Laie]

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!

[implementation]

Zitat:

Zitat von Delphi-Laie (Beitrag 1186014)

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!

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

[Delphi-Laie]

Zitat:

Zitat von implementation (Beitrag 1186016)

Zitat:

Zitat von Delphi-Laie (Beitrag 1186014)

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!

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!

[Uwe Raabe]

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

[himitsu]

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.

[Bernhard Geyer]

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

[Medium]

Zitat:

Zitat von himitsu (Beitrag 1186028)

siehe die geilen 64K-Programme

Von denen sind, neben gelegentlichen Handassemblierungen, fast alle aber auch gepackt ;) (Selten UPX, oft .kkrunchy, ab und an Eigenbauten der jeweiligen Crews)

@Topic:
Als Fan von beidem, kleinen Executables und komfortablen wartbarem Code, empfinde ich das Thema oft als Gratwanderung. Kleine Dateien erzeugen irgendwie einen Eindruck von "oh, da hat sich der Herr Compiler aber viel Mühe gegeben beim Optimieren, diese Sorgfalt legt er sicher auch an anderen Stellen an", wenn ich mir das aber über Einbußen im Umgang mit meinem Code erkaufen muss, entgleitet das zu einer Art Kunstform, die ich eher in meiner Freizeit zur Befriedigung meines Perfektionsdranges bei Nebensächlichkeiten sehe. Wenn ich mit Code Geld verdienen will, müssen die Quellen allen Komfort und zurück zulassen, da kümmert mich die Größe nicht mehr. Es sei denn es artet so weit aus, dass die Portabilität leidet. Nicht die zwischen diversen OS, sondern von mir zum Kunden. Die Größe darf meinetwegen hier also gerne mit den verfügbaren Übertragungswegen und Speichermedien mitwachsen, und das wäre das andere Ende meiner Gratwanderung.

Ob ich nun ein Framework brauche oder nicht, ist mir im Grunde auch fast egal. So lange es eines der auf Endanwender weit verbreiteten ist (im Prinzip .NET und JRE), und somit einen Quasi-Standard bildet, soll es mir eben so recht sein wie statisches Linking. Die angestellten Vergleiche hier sind teils wirklich recht... unbrauchbar und kaum ein Maß, und ich bezweifle, dass es da ein allgemeingültiges und rein technisch begründbares gibt. Hier ist einfach viel Präferenz im Spiel. Seitens des Entwicklers und auch des Kunden, und so lange beide mit einer Lösung leben können ist alles gut. Wenn nicht, dann hat der Kunde ein Programm, und der Dev einen Kunden weniger. Ob es einem von beiden wert ist seine Vorlieben zu ändern (und ggf. nen Stück Arbeit in Kauf zu nehmen) ist dann jedem selbst überlassen. Die Tools an sich sind alle gut, manche für Dinge besser als andere und umgekehrt, womit wieder einmal gilt: Das passende Werkzeug für die Aufgabe zu wählen ist schon halb programmiert :) Und wenn das Ziel kleine EXEn sind, dann war der Griff nach Delphi/FPC halt einfach schlecht. Als Entwickler ist es eben auch meine Aufgabe, zu wissen womit ich mein Ziel am besten erreiche. Wenn ich nachher feststelle, dass meine Wahl Murks war, dann kann man zwar nach Verbesserungen suchen, aber sicher nicht dem Tool die Schuld an meiner mangelnden Expertise/Recherche geben.

@Lazarus: Die Namen der Optionen sind allerdings wirklich etwas missverständlich ;). Solche Infos dürften da mindestens in Form eines Hits rein, oder aber gleich die Optionen so nennen, dass es eindeutig ist. Ich hätte das auch nie erahnt.

[Bernhard Geyer]

@Medium: :thumb: Kann dir nur voll zustimmen.

Bisher hat sich bei uns noch keiner über die Dateigröße (eher über Startzeiten der Exe bis zur Rückmeldung/Anzeige eines Splashscreens (vor einigen Jahren)) beschwert.
Und wir packen noch neben der Delphi-Exe eine JRE parallel zur Exe um manche Dinge in Java zu erledigen.

[Delphi-Laie]

Hallo himitsu!

Zitat:

Zitat von himitsu (Beitrag 1186028)

PS: Bei Delphi und Lazarus kann man auch noch so Einiges einsparen, wenn man gewisse Resourcen und Realocationstabellen rausschmeißt.

Was sind "gewisse Ressourcen"? Meintest Du die Laufzeittypinformationen (RTTI)? Das war das bisher heftigste (aber auch wirkungsvollste), was ich bisher bestritt, um die Compilatsgrößen zu verringern. Und wie entfernt man Reallocationstabellen? Gibt es dazu irgendwo eine Anleitung im Internet?

Besten Dank!

Viele Grüß

Delphi-Laie

[himitsu]

Weißt du wofür das Ding da ist?

Wenn Windows die Datei im Speicher verschieben muß, dann kann es darüber die Adressen anpassen.
Wird das nicht gemacht, dann funktioniert der Code nicht mehr und es passiert sonstwas Unschönes.

Ja, aktuell ist es so, daß Windows die EXE als Erstes in den Speicher läd, womit noch nirgendwo etwas belegt ist und die EXE (im Gegensatz zu einer DLL) nie verschoben werden muß.
Aber wer weiß ob Windows daran mal was ändert.
Und dann will man ja gleich noch mehr laden, also nutzt man UPX und Co., aber schon hat man ein grßes Problem, denn dann ist die "EXE" nicht mehr das Erste, denn der Preloader wird vorgeschaltet, welche die "EXE" dann entpackt und läd ... schwups, kann es sein, daß die "EXE" verschoben werden könnten und *peng*

Das war ein Beispiel dafür, was man machen könnte (wenn man weiß was man macht), aber was man nicht unbedingt machen sollte.
Stattdessen gibt es ja noch genügend "offizielle" Wege, wie man was loswerden könnte.
http://www.delphipraxis.net/170853-l...ml#post1185990
http://www.delphipraxis.net/170520-d...ml#post1183801
... (sowas Ähnliches wurde hier ja auch für Lazarus genannt)

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1186075)

Ja, aktuell ist es so, daß Windows die EXE als Erstes in den Speicher läd, womit noch nirgendwo etwas belegt ist und die EXE (im Gegensatz zu einer DLL) nie verschoben werden muß.
Aber wer weiß ob Windows daran mal was ändert.

ist doch schon:

Zitat:

When running native 64-bit binaries on Windows Vista and above, ASLR (Address Space Layout Randomization) is mandatory, and thus relocation sections cannot be omitted by the compiler.

(Aus Wiki)

[himitsu]

Cool, dann isses ja nun egal, daß fast alle bei den DLLs ständig vergessen die BaseAddress einzustellen. :stupid:

[implementation]

Zitat:

Zitat von Medium (Beitrag 1186054)

Kleine Dateien erzeugen irgendwie einen Eindruck von "oh, da hat sich der Herr Compiler aber viel Mühe gegeben beim Optimieren, diese Sorgfalt legt er sicher auch an anderen Stellen an"

Kann man auch anders betrachten: "Wenn die Programmierer so viel Zeit in die Optimierung gesteckt haben, muessen sie die Zeit ja irgendwo eingespart haben" :mrgreen:



@Relocation:
Gibt ja auch noch die Alternative des positionsunabhaengigen Codes. Empfinde ich vom Prinzip her als schoeneren Ansatz als alle Adressen vorm Ausfuehren zu aendern - selbst wenn es vllt. einige Nachteile mit sich bringen kann.