Wie bekomme ich die exe kleiner?

[NicoleWagner]

Danke für die Diskussion und das viele Wissen in alle Richtungen.
Ohne jetzt die Dinge bis aufs Letzte auszuquetschen: Die Letztfassung ist geschrumpft von ca 19 MB auf ca 6 MB+, also auf ca 1/3.

[Luckie]

Und mit was? Und wozu eigentlich?

[DieDolly]

Ich würde einfach auf Release stellen. Das reicht vollkommen. Die paar MB sind heute doch total egal. Windows-Phones sind eh am aussterben und das Datenvolumen über solche Handys somit auch :stupid:

[Delphi-Laie]

Zitat:

Zitat von DieDolly (Beitrag 1456862)

Ich würde einfach auf Release stellen. Das reicht vollkommen. Die paar MB sind heute doch total egal.

Na, das sehen z.B. die Administratoren so mancher Programmierforen aber ganz anders (deshalb Quotas), und das m.E. vollauf zurecht! Schließlich sind derlei begrenzte Ressourcen schließlich kostenpflichtig, was umso schwerer wiegt, wenn man diese dann kostenlos (und womöglich sogar noch unbegrenzt) anderen überläßt. Nicht umsonst gibt es die deutschen Sprichworte mit dem Kleinviehmist und dem Sich-Läppern.

[jaenicke]

Zitat:

Zitat von Delphi-Laie (Beitrag 1456872)

Na, das sehen z.B. die Administratoren so mancher Programmierforen aber ganz anders (deshalb Quotas), und das m.E. vollauf zurecht!

Das hat mit dem Thema doch gar nichts zu tun. Um Programme zu verteilen packt man diese natürlich ganz normal in ein 7Zip-Archiv, Setup oder ähnliches. Das hat aber ja nichts damit zu tun, ob die Dateien lokal dann zum Ausführen gepackt sind oder nicht.

Die Zips werden im Gegenteil sogar deutlich kleiner, wenn man z.B. zwei unkomprimierte Exen oder eine unkomprimierte Exe und eine unkomprimierte DLL einpackt, als wenn man diese vorher mit einem solchen Exe-Packer komprimiert!
Das ist ja auch logisch, denn viele Teile von zwei in Delphi erstellten Anwendungen sind ähnlich. Man denke nur an die ganzen System-Units usw., die einkompiliert sind. Wenn man diese aber packt, kann ein Zip-Tool diese nicht mehr so gut zusammenfassen.

Beispiel:
Unsere Kassenanwendung und die zugehörige Backoffice-Anwendung. Unkomprimiert 57,7 und 61 MiB groß, komprimiert mit Aspack 11,7 und 12,2 MiB.

Packmethode	Unkomprimierte Exen	Gepackt mit Aspack
Unkomprimiert	118,0 MiB	24,0 MiB
7zip	17,7 MiB	23,4 MiB

Man sieht, dass die Version mit den vorher komprimierten Exen glatt ein Drittel größer ist als die mit den vorher nicht komprimierten...

[Delphi-Laie]

Zitat:

Zitat von jaenicke (Beitrag 1456873)

Die Zips werden im Gegenteil sogar deutlich kleiner, wenn man z.B. zwei unkomprimierte Exen oder eine unkomprimierte Exe und eine unkomprimierte DLL einpackt, als wenn man diese vorher mit einem solchen Exe-Packer komprimiert!

Ja, natürlich tun sie das! Wiederholte Komprimationen führen oft bis allermeistens eher zu einer Aufblähung.

Aber eine Exe-Verkleinerung über einen Exe-Packer ist doch ohnehin gemogelt und mithin die unseriöseste Dateiverkleinerung.

Deshalb nannte ich diese Möglichkeit auch zuletzt und nur in Kammern.

Der guten Nicole Wagner ging es vermutlich auch und womöglich zuvörderst darum, die Exedatei wirklich zu verkleinern.

Sosehr ich Pascal liebe und mit Delphi und Lazarus gern programmiere, sosehr hat mich die zunemende Verfettung ihrer Compilate im Verlaufe der Versionsfortschritte immer gestört.

Echt kleine Exedateien, und dann noch hochkomprimiert über zip, rar, 7zip (und noch besseres) sind das kleinste überhaupt und am ressourcenschonendsten auf Permanentspeichern!

[haentschman]

Moin...8-)
[nur meine Meinung]

Zitat:

im Verlaufe der Versionsfortschritte

:? ... versuch mal im Autohaus ein neues Auto zu bekommen was keinen Airbag hat. Es ist deine Entscheidung ob du mit einem Golf Bj.67 fährst oder die modernen Sprachfeatures nutzt. :roll:
[/nur meine Meinung]

[Stevie]

Zitat:

Zitat von haentschman (Beitrag 1456878)

Moin...8-)
[nur meine Meinung]

Zitat:

im Verlaufe der Versionsfortschritte

:? ... versuch mal im Autohaus ein neues Auto zu bekommen was keinen Airbag hat. Es ist deine Entscheidung ob du mit einem Golf Bj.67 fährst oder die modernen Sprachfeatures nutzt. :roll:
[/nur meine Meinung]

Es ist ein kleiner Unterschied, ob du etwas bekommst, was du nur im Notfall (dann aber auf jeden Fall) benötigst, oder ob du immer alles dabei gepackt bekommst, was du nicht brauchst.
Um mal beim hinkenden Autobeispiel zu bleiben, ist das so, als ob du immer im Kofferraum und auf dem Dachgepäckträgger Wasser- und Wintersportausrüstung transportierst, egal wo du hinfährst.

Es ist ein großer Unterschied, ob man die Kosten für eine Funktionialität, die man auch nutzt, trägt, oder sie auch trägt, obwohl man sie überhaupt nicht benutzt.

[Moombas]

Zitat:

Zitat von Stevie (Beitrag 1456900)

Es ist ein kleiner Unterschied, ob du etwas bekommst, was du nur im Notfall (dann aber auf jeden Fall) benötigst, oder ob du immer alles dabei gepackt bekommst, was du nicht brauchst.

Bezogen auf das Autobeispiel: Das ist fast immer so, das du Sachen dazu bekommst die du durch die Gegend fährst obwohl du es niemals brauchst (ob Notfall oder nicht). Und wenn es nur der Überdimensionierte Motor (und alles was dann damit zusammenhängt) ist, weil man eine höhere Ausstattung haben möchte um die komplette Sicherheitsausstattung zu bekommen... diese aber nur mit dem größten Motor zu haben ist.


Aber dennoch Stimme ich bei Delphi zu, wenn eine .exe erzeugt wird, muss nicht alles rein. Gerade bei Software könnte man beim erzeugen "intelligent abspecken" (alles raus was nicht benötigt wird) bzw. "intelligent packen" (nur rein was auch zusätzlich gebraucht wird). Zumindest wäre dies meine Erwartungshaltung.

[Sherlock]

Zitat:

Zitat von haentschman (Beitrag 1456878)

Moin...8-)
[nur meine Meinung]

Zitat:

im Verlaufe der Versionsfortschritte

:? ... versuch mal im Autohaus ein neues Auto zu bekommen was keinen Airbag hat.

Das nennt man Motorrad, kenne die Fachbegriffe. :warn:

Sherlock

[jaenicke]

Zitat:

Zitat von Moombas (Beitrag 1456904)

Aber dennoch Stimme ich bei Delphi zu, wenn eine .exe erzeugt wird, muss nicht alles rein. Gerade bei Software könnte man beim erzeugen "intelligent abspecken" (alles raus was nicht benötigt wird) bzw. "intelligent packen" (nur rein was auch zusätzlich gebraucht wird). Zumindest wäre dies meine Erwartungshaltung.

Wenn alles drin wäre, wären die Anwendungen noch deutlich größer. Das Problem ist einfach, dass man nicht unbedingt etwas direkt ansprechen muss, es aber dennoch benutzen kann. Wenn man eine Methode über die RTTI über den Namen anspricht, wäre es halt doof, wenn der Compiler diese nicht mit kompiliert hätte, weil sie ansonsten nicht verwendet wird.

Von daher mag das zwar leicht erscheinen, ist es aber nicht...

[Delphi-Laie]

Zitat:

Zitat von Moombas (Beitrag 1456904)

Aber dennoch Stimme ich bei Delphi zu, wenn eine .exe erzeugt wird, muss nicht alles rein. Gerade bei Software könnte man beim erzeugen "intelligent abspecken" (alles raus was nicht benötigt wird) bzw. "intelligent packen" (nur rein was auch zusätzlich gebraucht wird). Zumindest wäre dies meine Erwartungshaltung.

Eben - meine auch!

Delphi hat bis heute einen sehr schnellen Compiler. Zum einen, weil der wohl nur einen Durchgang benötigt, zum anderen wirkt da wohl noch die Zeit, als Turbopascal in Maschinencode programmiert wurde, nach (waren das noch Zeiten sehr guter Softwarequalität, ich denke da auch an WordPerfect und Geoworks Ensemble!).

Doch für die Größe der Compilate wurde entweder wenig bis gar nichts oder jedenfalls wohl nicht so viel Entwicklungsarbeit wie in andere Dinge gesteckt- leider. Einzige Ausnahme, die ich bislang wahrnahm: Von Delphi 6 auf Delphi 7 kann es tatsächlich sogar kleiner werden.

Die von jaenicke genannten Datei-/Projektgrößen wirken zunächst einmal erschlagend. Keine Ahnung, wieviele Compilate diese Gesamtgröße verursachen.

Ja, und natürlich ist mir klar, daß 64 Bit per se größere Compilate als 32 Bit verursachen muß, das war schon beim Übergang von 16 auf 32 Bit so und natürlich auch, als der Standard von Konsole auf Windows visuelle Komponentne umgestellt wurde. Außerdem bin ich mir sicher, daß andere Programmiersprachen ebenfalls mit diesem Phänomen zu kämpfen haben (oder eher das Internet, die Computer und ihre Benutzer).

Dennoch tauchen solche Exe-Verkleinerungsfragen immer wieder in den Foren auf, eben, weil sie berechtigt sind.

[Stevie]

Zitat:

Zitat von jaenicke (Beitrag 1456942)

Von daher mag das zwar leicht erscheinen, ist es aber nicht...

Doch ist es - es hat nur keine Priorität. Teil der immer größer werdenden Binaries sind auch zu einem signifikanten Teil die Generics, die in den Standardbibliotheken genutzt werden aber vom Compiler nicht eingedampft werden.

Eine leere VCL Anwendung in Delphi 10.3.3 auf Release ist bei mir knappe 2.4MB groß.
Davon sind über 800KB nur Code aus Generics:
59 verschiedene TList<> (ca 400KB)
14 verschiedene TDictionary<,> (ca 120KB)

Von den Listen könnte es 14 weniger geben, wenn man nicht so dämlichen Code in TEnumerable<T>.ToArray schreiben würde, wie derzeit der Fall ist. Denn das sorgt dafür, dass auch für ein TDictionary<TFoo,TBar> eine TList<TPair<TFoo,TBar>> kompiliert wird, die vermutlich niemals nicht benutzt wird.

Und von den dann noch übrig beleibenden 45 Listen könnten grob überschlagen über die Hälfte einfach auf TList<TObject> eingedampt werden, da es alle TList<T> sind, wo T eine Klasse ist.

Bei einer FMX Anwendung sieht das ganze übrigens noch weitaus schlimmer aus. Wenn man dann noch Drittanbieter Komponenten nutzt, die mit wachsender Begeisterung die RTL Collections nutzen, zieht man sich noch mehr unnützen Klump rein.

Im übrigen ist das meiste des Codes, den so eine TList<T> in der Binary verursacht sogar Code der niemals durchlaufen wird, da sie für Aufrufe inlined werden - aber da nunmal für jeden RTL Typ RTTI angeschaltet ist, kann der Linker sie nicht rauswerfen.

[Luckie]

Kann man die RTTI (oder wie heißt das?) eigentlich einfach deaktivieren, wenn man sie nicht benötigt? Und wie viel ändert das an der Größe?

[jaenicke]

Zitat:

Zitat von Luckie (Beitrag 1456947)

Kann man die RTTI (oder wie heißt das?) eigentlich einfach deaktivieren, wenn man sie nicht benötigt? Und wie viel ändert das an der Größe?

Das ändert aber nichts daran, dass sie in den Systembibliotheken aktiv ist. Zudem verwenden wir z.B. diese Funktionalitäten auch aktiv (eigene Skriptsprache, ...).

[venice2]

Zitat:

Eine leere VCL Anwendung in Delphi 10.3.3 auf Release ist bei mir knappe 2.4MB groß.
Davon sind über 800KB nur Code aus Generics:
59 verschiedene TList<> (ca 400KB)
14 verschiedene TDictionary<,> (ca 120KB)

Deshalb ist Delphi auch so beliebt :stupid:

Zitat:

Und wie viel ändert das an der Größe?

200 -> 300KB

@Stevie :thumb:

[Stevie]

Zitat:

Zitat von Luckie (Beitrag 1456947)

Kann man die RTTI (oder wie heißt das?) eigentlich einfach deaktivieren, wenn man sie nicht benötigt? Und wie viel ändert das an der Größe?

RTTI für System.Generics.Collections ausgeschalten, TEnumerable<T>.ToArray virtual abstract gemacht und noch ein paar kleinere Anpassungen in System.Generics.Defaults -> 1.6MB, davon 134KB durch Generics (14 TDictionary<,> und 29 TList<>).

Warum 30 Listen weniger? Ich vergaß: TDictionary<TKey, TValue> hat intern Klassen, die von TEnumerable<TKey> und TEnumerable<TValue> ableiten, somit bekam man pro TDictionary<,> 3 neue TList<> Klassen (für TKey, TValue und TPair<TKey,TValue>) - wären also im besten Fall 42 mal TList<> weniger - einige Kombinationen sind aber noch wirklich als TList<> benutzt - z.B. wenn ein TDictionary als key TClass hat, denn TList<TClass> wird irgendwo benutzt.

[Delphi-Laie]

Zitat:

Zitat von Luckie (Beitrag 1456947)

Kann man die RTTI (oder wie heißt das?) eigentlich einfach deaktivieren, wenn man sie nicht benötigt? Und wie viel ändert das an der Größe?

In der Projektdatei gibt es dafür eine Option (siehe meinen ersten Beitrag in dieser Diskussion).

Die RTTI aus den vorcompilierten Units herauszubekommen, ist ein Kraftakt, der mal im Internet beschrieben war und den ich bei Delphi XE 2 sogar schaffte. Ausnahme: Aus den system.dcu(s) und den sysutils.dcu(s) war es nicht möglich, deren Quelltexte ließen sich nicht erneut compilieren.

Macht deutlich was aus, die RTTI herauszulösen.

[TurboMagic]

Zitat:

Zitat von Sherlock (Beitrag 1456913)

Zitat:

Zitat von haentschman (Beitrag 1456878)

Moin...8-)
[nur meine Meinung]

Zitat:

im Verlaufe der Versionsfortschritte

:? ... versuch mal im Autohaus ein neues Auto zu bekommen was keinen Airbag hat.

Das nennt man Motorrad, kenne die Fachbegriffe. :warn:

Sherlock

Ähm, gab's nicht von irgend einem hersteller nicht auch schon mal einen Airbag für's Motorrad?
Jedenfalls gibt's scheinbar sowas für Fahrrad und Motorradhelme inzwischen...

[TurboMagic]

Zitat:

Zitat von Moombas (Beitrag 1456904)

Zitat:

Zitat von Stevie (Beitrag 1456900)

Es ist ein kleiner Unterschied, ob du etwas bekommst, was du nur im Notfall (dann aber auf jeden Fall) benötigst, oder ob du immer alles dabei gepackt bekommst, was du nicht brauchst.

Bezogen auf das Autobeispiel: Das ist fast immer so, das du Sachen dazu bekommst die du durch die Gegend fährst obwohl du es niemals brauchst (ob Notfall oder nicht). Und wenn es nur der Überdimensionierte Motor (und alles was dann damit zusammenhängt) ist, weil man eine höhere Ausstattung haben möchte um die komplette Sicherheitsausstattung zu bekommen... diese aber nur mit dem größten Motor zu haben ist.


Aber dennoch Stimme ich bei Delphi zu, wenn eine .exe erzeugt wird, muss nicht alles rein. Gerade bei Software könnte man beim erzeugen "intelligent abspecken" (alles raus was nicht benötigt wird) bzw. "intelligent packen" (nur rein was auch zusätzlich gebraucht wird). Zumindest wäre dies meine Erwartungshaltung.

Naja, ein Stück weit speckt der Compiler/Linker schon ab. Nennt sich Smartlinking.
Nur können bei komplett abgeschaltetem RTTI viele Dinge nicht mehr raus die früher rausgekonnt hätten,
da der Compiler/Linker u.U. nicht mehr so leicht wissen kann, ob das Zeugs nicht doch zur Laufzeit
dynamisch aufgerufen wird.

Grüße
TurboMagic

[TurboMagic]

Zitat:

Zitat von Luckie (Beitrag 1456947)

Kann man die RTTI (oder wie heißt das?) eigentlich einfach deaktivieren, wenn man sie nicht benötigt? Und wie viel ändert das an der Größe?

Hallo,

per Unit kannst du zumindest Teile davon auch abschalten. Du kanst dir sogar
raussuchen welche. Icxh weiß nur nicht mehr auswendig wie das Stichwort dazu lautet.
Es gibt aber eine Direktive die man an den Anfang der Unit schreibt.

Grüße
TurboMagic

[TurboMagic]

Zitat:

Zitat von Stevie (Beitrag 1456954)

Zitat:

Zitat von Luckie (Beitrag 1456947)

Kann man die RTTI (oder wie heißt das?) eigentlich einfach deaktivieren, wenn man sie nicht benötigt? Und wie viel ändert das an der Größe?

RTTI für System.Generics.Collections ausgeschalten, TEnumerable<T>.ToArray virtual abstract gemacht und noch ein paar kleinere Anpassungen in System.Generics.Defaults -> 1.6MB, davon 134KB durch Generics (14 TDictionary<,> und 29 TList<>).

Warum 30 Listen weniger? Ich vergaß: TDictionary<TKey, TValue> hat intern Klassen, die von TEnumerable<TKey> und TEnumerable<TValue> ableiten, somit bekam man pro TDictionary<,> 3 neue TList<> Klassen (für TKey, TValue und TPair<TKey,TValue>) - wären also im besten Fall 42 mal TList<> weniger - einige Kombinationen sind aber noch wirklich als TList<> benutzt - z.B. wenn ein TDictionary als key TClass hat, denn TList<TClass> wird irgendwo benutzt.

Gibt's für diese Ideen schon QP feature requests? ;-)

[Stevie]

Zitat:

Zitat von TurboMagic (Beitrag 1456961)

Gibt's für diese Ideen schon QP feature requests? ;-)

Nein, ich trage Dinge nicht mehr ein, wo ich von vornherein weiß, dass sie nicht gemacht werden.
- die Änderung für TEnumerable<T>.ToArray hab ich an einen Entwickler kommuniziert und das wird wohl in 10.4 drin sein (10.3.x ging nicht, da breaking change).
- RTTI ausschalten werden sie nicht machen, da dann der ganze JSON und sonstiges jegliches Serialisieren nicht mehr funktioniert.
- die Änderungen in System.Generics.Defaults, die ich gemacht habe sind auch Breaking changes (TComparer<T> und TEqualityComparer<T> auf record geändert, so dass dort weniger unnötiger Code erstellt wird)

[himitsu]

Wird als Optimierung intern auch der selbe Code verwendet, wenn die Typen quasi kompatibel sind, bzw. wo praktisch der selbe Assembler-Code entsteht?

z.B. TDictionary für Byte, ShortInt, PAnsiChar, Boolean, ByteEnum usw.



Und warum nicht die meiste RTTI aus, wenn sie fast niegendwo verwendet wird?
Die Objekte/Typen, welche Serialisiert werden sollen, da ist es keinerlei großer Aufwand, wenn die Entwickler das dort gezielt aktivieren.

Aber gut, es war auch schonmal witzig per RTTI bissl durch die IDE zu enumerieren, obwohl dort leider doch bei dem Einen oder Anderen die RTTI deaktiviert wurde. :cry: