Größe Exe-Datei XE2 -> XE4

[Bernhard Geyer]

Hab jetzt mein erstes Programm mit XE4 kompiliert.
Und die Exegröße ist wieder stark gestiegen:

D6 - 787 kByte
XE2 - 3170 kByte
XE4 - 4282 kByte.

Welches sind die Optionen mit denen man die Exegröße halbwegs verkleinern kann.
Exe-Packer ist keine Option.

[Sir Rufo]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1212701)

Hab jetzt mein erstes Programm mit XE4 kompiliert.
Und die Exegröße ist wieder stark gestiegen:

D6 - 787 kByte
XE2 - 3170 kByte
XE4 - 4282 kByte.

Welches sind die Optionen mit denen man die Exegröße halbwegs verkleinern kann.
Exe-Packer ist keine Option.

Bitte die Compiler-Optionen dabei schreiben :roll:
Debug oder Release
Mit Debug-DCU oder nicht
Mit erweitertem RTTI oder nicht

[Der schöne Günther]

Aber warum sollte es von XE2 auf XE4 steigen? Dinge wie ARC stecken doch angeblich nur im ARM-Compiler?

Oder vielleicht ganz versteckt auch schon im x86-Compiler, wer weiß :smile2:

[Sir Rufo]

Zitat:

Zitat von Der schöne Günther (Beitrag 1212708)

Aber warum sollte es von XE2 auf XE4 steigen? Dinge wie ARC stecken doch angeblich nur im ARM-Compiler?

Oder vielleicht ganz versteckt auch schon im x86-Compiler, wer weiß :smile2:

Wenn z.B. die SysUtils um ein paar Funktionen erweitert wurde dann wird die komplette (größere) SysUtils.dcu in dein Projekt compiliert. Rein rechnerisch wird es dadurch nicht kleiner.

[Bernhard Geyer]

Zitat:

Zitat von Sir Rufo (Beitrag 1212707)

Bitte die Compiler-Optionen dabei schreiben :roll:
Debug oder Release
Mit Debug-DCU oder nicht
Mit erweitertem RTTI oder nicht

Der zuwachs D6 -> XE2 ist mir klar.

Es geht primär um die XE4-Zuwachs da ich hier das XE2-Projekt genommen habe und somit die gleichen Optionen wirken.
Ich will erstmal wissen welche Optione überhaupt hier den Zuwachs beeinflussen können damit ich mal damit herum spielen kann.

[Daniel]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1212701)

Welches sind die Optionen mit denen man die Exegröße halbwegs verkleinern kann.

Ich verwende da die folgenden Zeilen für eine Release-Konfiguration:

Delphi-Quellcode:

// nur benoetigte Typen einbinden (XE3-Standard == off)
{$STRONGLINKTYPES OFF}

// nur aufgerufene Methoden einbinden (XE3-Standard == off)
{$WEAKLINKRTTI ON}

// keine RTTI-informationen generieren
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}

Ein wenig Größer wird's hier auch. Unter XE3 wird mir bei einem meiner Win32-Projekte eine Dateigröße von 2377 KByte generiert, die selben Sourcen kompilieren unter XE4 zu einer Größe von 2438 KByte.

ARC selbst steckt nicht nur angeblich, sondern tatsächlich nur im ARC-Compiler. Aber natürlich wird die Laufzeitbibliothek mit den Versionen geändert und ggf. wird's dann halt auch mal größer.

[Bernhard Geyer]

Autsch. :wall: War viel einfacher.
Hatte es versehentlich für x64 Compiliert. Da darf es natürlich wachsen.

Als XE4-x32-Version ist es fast 1MB kleiner als die XE2-Version.

[UliBru]

Zitat:

Zitat von Daniel (Beitrag 1212711)

Ich verwende da die folgenden Zeilen für eine Release-Konfiguration:

Delphi-Quellcode:

// nur benoetigte Typen einbinden (XE3-Standard == off)
{$STRONGLINKTYPES OFF}

// nur aufgerufene Methoden einbinden (XE3-Standard == off)
{$WEAKLINKRTTI ON}

// keine RTTI-informationen generieren
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}

Macht es also nicht generell Sinn, gleich in die dpr-Projektdatei reinzuschreiben ?

Delphi-Quellcode:

{$IFNDEF DEBUG}

// nur benoetigte Typen einbinden (XE3-Standard == off)
{$STRONGLINKTYPES OFF}

// nur aufgerufene Methoden einbinden (XE3-Standard == off)
{$WEAKLINKRTTI ON}

// keine RTTI-informationen generieren
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}

{$ENDIF}

Oder andersrum gefragt, wann braucht man eigentlich die RTTI für ein normales Programm bzw. wann gibt es mit o.g. Code Probleme?

[Daniel]

Die RTTI-Infos benötigst Du genau dann, wenn Du zur Laufzeit dynamisch auf Deine Objekte zugreifen möchtest. Wenn Du also z.B. wissen möchtest, ob Dein Objekt "Kunde" eine Eigenschaft mit dem Namen "Nummer" hat und von welchem Typ sie ist. Es gibt eine Vielzahl an Verwendungsmöglichkeiten (siehe auch Stichwort "Reflection") - aber bei Weitem nicht alle Programme benötigen diese Möglichkeiten.

Der Moment, in dem Du Dich fragst, wozu das gut ist, sollte schon ein hinreichendes Indiz dafür sein, dass Du es nicht verwendest, denn sonst wüsstest Du es. ;-) (Stark verkürzte Aussage, ich weiß ...)

Diese Dynamik bringt ein weiteres Problem: Du könntest eine Methode über ihren Namen aufrufen. Den Namen legst Du in einen String und im Extremfall lässt Du diesen String vom Anwender ausfüllen. Der Compiler kann daher unmöglich wissen, welche Methode eventuell zur Laufzeit benötigt werden könnte und hat keine andere Wahl, als alle Methoden in die EXE zu schubsen - denn theoretisch könnten sie mittels RTTI aufgerufen werden. Wenn Du aber weisst, dass Du das nicht machst, dann kannst Du den Compiler anweisen, dass er ausschliesslich die Methoden in die EXE schreiben soll, die per Code festverdrahtet aufgerufen werden. Das macht die EXE auch noch mal ein gutes Stück kleiner.

[p80286]

Zitat:

Zitat von Sir Rufo (Beitrag 1212709)

Wenn z.B. die SysUtils um ein paar Funktionen erweitert wurde dann wird die komplette (größere) SysUtils.dcu in dein Projekt compiliert. Rein rechnerisch wird es dadurch nicht kleiner.

War da nicht mal was mit "nur was benötigt wird wird auch compiliert"?

Gruß
K-H

[Sir Rufo]

Zitat:

Zitat von p80286 (Beitrag 1212727)

Zitat:

Zitat von Sir Rufo (Beitrag 1212709)

Wenn z.B. die SysUtils um ein paar Funktionen erweitert wurde dann wird die komplette (größere) SysUtils.dcu in dein Projekt compiliert. Rein rechnerisch wird es dadurch nicht kleiner.

War da nicht mal was mit "nur was benötigt wird wird auch compiliert"?

Gruß
K-H

Wenn eine DCU vorliegt, dann wird die nicht mehr compiliert ;)

PS: Und es ist immer wieder schön zu sehen, wenn einige Packages nur im Debug-Modus erstellt werden. Das geht dann auch so in das Programm rein, egal ob Release oder nicht

[Stevie]

Zitat:

Zitat von Daniel (Beitrag 1212724)

Der Moment, in dem Du Dich fragst, wozu das gut ist, sollte schon ein hinreichendes Indiz dafür sein, dass Du es nicht verwendest, denn sonst wüsstest Du es. ;-) (Stark verkürzte Aussage, ich weiß ...)

Da möchte ich mal dezent widersprechen - ich weiß nicht, ob jedem direkt klar ist, dass LiveBindings nur mit RTTI funktionieren.

Zitat:

Zitat von Sir Rufo (Beitrag 1212729)

Wenn eine DCU vorliegt, dann wird die nicht mehr compiliert ;)

PS: Und es ist immer wieder schön zu sehen, wenn einige Packages nur im Debug-Modus erstellt werden. Das geht dann auch so in das Programm rein, egal ob Release oder nicht

Verwechsel hier nicht Compilereinstellungen (Release oder Debug) mit dem entfernen von ungenutztem Code durch den Linker.

Kompiliert wird immer alles, was im Projekt vorhanden ist - sofern der Code vorhanden (leicht zu testen, indem du in eine Methode, die niemals aufgerufen wird, einen Compilefehler einbaust). Allerdings entfernt Linker danach dann soweit möglich das, was nicht benutzt wird.

Aus diesem Grunde muss man sich manchmal mit kleinen Tricks behelfen, dass eine Klasse drin bleibt (indem man sie z.b. im initialization Part referenziert), wenn sie nämlich nur über RTTI anspricht.

[sx2008]

Mit StripReloc kann man 32bit Executables noch einige Prozent verkleinern indem die unnötige Relocation-Tabelle entfernt wird.

[Delphi-Laie]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1212712)

Als XE4-x32-Version ist es fast 1MB kleiner als die XE2-Version.

Wie, das Nachfolgedelphi (übernächste Version) generiert ein deutlich kleineres Compilat?

Hatte ich bisher grundsätzlich anders, nämlich umgekehrt erfahren. Ein Problem, das Borland & Co. nie in den Griff bekamen - sofern sie es als solches überhauupt erkannten und angingen.

Ansonsten kann man mit viel Handarbeit einiges erreichen: http://www.zipplet.co.uk/index.php/c...delphi2010rtti

Zitat:

Zitat von Sir Rufo (Beitrag 1212707)

Mit erweitertem RTTI oder nicht

Darf ich fragen, wo man "erweiterte" RTTI ein- bzw. ausschalten kann? Wenn es "erweiterte" gibt, muß es zudem logischerweise auch einfache geben. Ich kenne nur die, was sich (weitgehend) entfernen lassen, ohne in einfache oder erweiterte zu unterscheiden.

[Sir Rufo]

Published Properties können schon gefühlt seit Ewigkeiten ausgelesen werden (RTTI).

Für den Zugriff auf Fields (private, protected, etc.) wird aber die erweiterte RTTI benötigt

[UliBru]

Zitat:

Zitat von Daniel (Beitrag 1212724)

Die RTTI-Infos benötigst Du genau dann, wenn Du zur Laufzeit dynamisch auf Deine Objekte zugreifen möchtest.
...
Der Moment, in dem Du Dich fragst, wozu das gut ist, sollte schon ein hinreichendes Indiz dafür sein, dass Du es nicht verwendest, denn sonst wüsstest Du es. ;-) (Stark verkürzte Aussage, ich weiß ...)

Ich weiss für mich in diesem Sinn wohl, dass ich da selbst keine RTTI-Info verwende. Ich weiss aber nicht, ob da nicht in einer der verwendeten Bibliotheken vielleicht jemand davon Gebrauch macht. Kann man das feststellen?

Grüsse
Uli

[Bernhard Geyer]

Zitat:

Zitat von UliBru (Beitrag 1212792)

Ich weiss für mich in diesem Sinn wohl, dass ich da selbst keine RTTI-Info verwende. Ich weiss aber nicht, ob da nicht in einer der verwendeten Bibliotheken vielleicht jemand davon Gebrauch macht. Kann man das feststellen?

Die Basis-RTTI ist zwingend nötig. Sonst könnte die Exe die Formulare aus den dfm's nicht mehr herstellen.

Bei der erweiterten RTTI wird es darauf ankommen welche Minimale Delphi-Version sie unterstützt. Falls D7 dabei ist wird sie nicht benötigt.
Ansonsten mal den Hersteller fragen. Dieser sollte über IFOPT-Abfraggen entsprechende Compilerfehler erzeugen falls er sie benötigt aber nicht vorhanden sind.

[Der schöne Günther]

Gerade XE4 installiert, das gleiche Projekt ist (Debug-Fassung) ist von XE2 auf XE4 von 8,44 auf 11,8MB gewachsen. Nicht dass es mich stören würde, aber schon heftig...

[Stevie]

Die Benutzung von Generics in der RTL (glaube ab XE3) äußert sich nunmal in einer größeren Binary.

[MEissing]

http://blogs.embarcadero.com/matthia...13/04/26/38698

[Der schöne Günther]

Danke.

Aber wie gesagt, mich stört es nicht. Ich bin nur neugierig, was sich denn von XE2 auf XE4 in einer reinen Win32-Anwendung ohne FM geändert haben könnte. Was sollte sich denn bei den Generics noch geändert haben?

[jbg]

Bei den Generics hat sich geändert, dass ab XE3 die RTL und VCL von TList/TObjectList auf TList<Alle möglichen Klassen> umgestellt wurde. Das bedeutet, dass statt der einen TList/TObjectList Klasse nun um einiges mehr TList<T> herumschwirren, da der Compiler für jedes T eine eigene Kopie anfertigt.

Was früher eine einzige TList mit Typecasts war, ist jetzt TList<TAction>, TList<TComponent>, TList<TField>, TList<...>, ...

Codegenerier-technisch könnte man all die Listen wieder zu einer zusammenfassen, da keine dieser auf irgendwelche speziellen Eigenschaften der Klassen zugreift, also alle mit einem TList<TObject> abbildbar wären. Ein harter Typecast ist nämlich in wirklichkeit nur eine Uminterpretation der Daten, was in Fall von Objekt-Referenzen zu keinem einzigen Maschinencode-Byte führt.
Aber das wollen die für den Compiler Verantwortlichen nicht implementieren.

[Stevie]

Zitat:

Zitat von Matthias Eissing

Weiß man nicht, was RTTI ist, kann man das auch ausschalten.

Falsch - genau das Gegenteil ist der Fall. Man muss nämlich sehr genau wissen, was RTTI ist, und ob irgendein Code in der Anwendung diese benötigt.
Inzwischen wird nämlich in vielen unterschiedlichen Teilen diese oft genutzt - einige Beispiele wären: Serialisierung, ORM, DI und *trommenwirbel* LiveBindings.

[MEissing]

Zitat:

Zitat von Stevie (Beitrag 1215592)

Zitat:

Zitat von Matthias Eissing

Weiß man nicht, was RTTI ist, kann man das auch ausschalten.

Falsch - genau das Gegenteil ist der Fall. Man muss nämlich sehr genau wissen, was RTTI ist, und ob irgendein Code in der Anwendung diese benötigt.
Inzwischen wird nämlich in vielen unterschiedlichen Teilen diese oft genutzt - einige Beispiele wären: Serialisierung, ORM, DI und *trommenwirbel* LiveBindings.

...du hast ein prominentes Beispiel vergessen: DataSnap.

Aber "Danke" für die "zielgerichtete Klarstellung".

[Stevie]

Zitat:

Zitat von MEissing (Beitrag 1215599)

...du hast ein prominentes Beispiel vergessen: DataSnap.

Aber "Danke" für die "zielgerichtete Klarstellung".

Siehste - ich nutz es nicht, und weiß daher nicht, wie es intern funktioniert. :)

P.S. sollen die "" etwa Ironie zum Ausdruck bringen?

[Der schöne Günther]

Zitat:

Zitat von jbg (Beitrag 1215572)

Bei den Generics hat sich geändert, dass ab XE3 die RTL und VCL von TList/TObjectList auf TList<Alle möglichen Klassen> umgestellt wurde.

Ok, das war mir neu. :thumb:

[sh17]

Zitat:

Zitat von jbg (Beitrag 1215572)

Bei den Generics hat sich geändert, dass ab XE3 die RTL und VCL von TList/TObjectList auf TList<Alle möglichen Klassen> umgestellt wurde. Das bedeutet, dass statt der einen TList/TObjectList Klasse nun um einiges mehr TList<T> herumschwirren, da der Compiler für jedes T eine eigene Kopie anfertigt.

Was früher eine einzige TList mit Typecasts war, ist jetzt TList<TAction>, TList<TComponent>, TList<TField>, TList<...>, ...

Codegenerier-technisch könnte man all die Listen wieder zu einer zusammenfassen, da keine dieser auf irgendwelche speziellen Eigenschaften der Klassen zugreift, also alle mit einem TList<TObject> abbildbar wären. Ein harter Typecast ist nämlich in wirklichkeit nur eine Uminterpretation der Daten, was in Fall von Objekt-Referenzen zu keinem einzigen Maschinencode-Byte führt.
Aber das wollen die für den Compiler Verantwortlichen nicht implementieren.

Hab das mal getestet, das ist ja übel - mit jedem neuen generischem Typ wächst die Exe um rund 20k. Wenn ich da jetzt richtig von gebrauch machen würde und alle unsere um die 50 abgeleiteten TObjectLists auf Generics umstellen würden ...... grusel

[Der schöne Günther]

Ich habe das nie verstanden, warum die Dinger dann Generics genannt werden und nicht Templates? Denn das sind sie dann im Endeffekt doch, oder?

PS: Von Generics in .Net bzw. deren Unterschied zu C++ Templates habe ich keine Ahnung.

[jaenicke]

Zitat:

Zitat von sh17 (Beitrag 1255566)

Hab das mal getestet, das ist ja übel - mit jedem neuen generischem Typ wächst die Exe um rund 20k. Wenn ich da jetzt richtig von gebrauch machen würde und alle unsere um die 50 abgeleiteten TObjectLists auf Generics umstellen würden ...... grusel

Ja, unsere Exe wächst auch ziemlich stark, mittlerweile sind das rund 50 MiB, früher waren es mal unter 10 MiB, natürlich auch mit ein wenig weniger Funktionalität. Aber ein Problem sehe ich da nicht, auch wenn es natürlich schöner wäre, wenn sie kleiner wäre.

[CocoPops]

Gemeinde.

Ich bin Besitzer einer XE2-Version.
Ich möchte gerne auf XE4 umsteigen, nicht XE5!

Welche Unterschiede gibt es zwischen XE2 und XE4 bezüglich der Exe-Datei? Ist der Code besser, optimierter oder ähnliches?

[mkinzler]

XE4 sollte sich nicht großartg von XE5 unterscheiden, du kannst also gleich XE5 oder bald XE6 verwenden.

[CocoPops]

Und was ändert sich bezüglich der finalen Exe-Datei? Ist sie in irgendeiner Weise kompatibler?

[mkinzler]

Wie meinst Du das? Was verstehst Du unter kompatibler? Kompatibel zu was?

[CocoPops]

Was ich wissen wollte ist, ob der XE4/5/6 Code in irgendeiner Weise besser/optimierter ist als der von XE2.
Denn wenn das überhaupt nichts ändert, dann bleibe ich bei XE2 und spare mein Geld.

[Der schöne Günther]

Dich interessiert also nur der Win32/Win64-Compiler mit VCL, richtig? Sprachänderungen (Helper!), Bugfixes und anderes nicht?

Von XE2 auf XE3 hat sich, glaube ich, praktisch nichts getan, ab XE4 sind die Attribute [Ref], [Volatile] und [Weak] (letzteres auf Windows noch nicht) neu und interessant.

Ich weiß ja nicht was du genau vorhast oder dir erhoffst, aber brachiale Änderungen wirst du wohl nicht erwarten können 8-)


Ansonsten: Siehe auch:
- http://docwiki.embarcadero.com/RADSt...%2BBuilder_XE3
- http://docwiki.embarcadero.com/RADSt...hanges_for_XE4

[Bernhard Geyer]

Zitat:

Zitat von CocoPops (Beitrag 1255600)

Was ich wissen wollte ist, ob der XE4/5/6 Code in irgendeiner Weise besser/optimierter ist als der von XE2.
Denn wenn das überhaupt nichts ändert, dann bleibe ich bei XE2 und spare mein Geld.

Der Focus neuerer Delphi-Versionen ist primär auf Mobile Entwicklung (iOS, Android).
Im Bereich "klassicher" Desktopentwicklung wirst du mit XE3+ nicht viel gewinnen.
Siehe auch: https://www.embarcadero.com/de/produ...lphi/whats-new

[CocoPops]

Genau, die Sprachveränderungen und Änderungen des COmpilers interessierTEN mich.
Werde das mal durchlesen. Aber da ich mich nicht für Mobile Development interessiere, denke ich, dass ich bei XE2 bleibe und spare.

[Der schöne Günther]

Ich bin nicht ganz im Bilde da ich kurz XE2 angetestet hatte und mit XE4 erst richtig eingestiegen bin, aber ich meinte gehört zu haben, dass vor allem bei Generics auch nach XE2 noch ordentlich ge-bugfixt wurde.

Die Class Helper/Record Helper sind ab XE3 auch für eingebaute Typen wie Integer möglich und ab XE4 auch mit einer Standard-Implementierung dabei. Die würde ich wirklich schmerzlichst vermissen.

Ab XE5 kamen wohl tolle REST-Bibliotheken hinzu, aber die habe ich noch nicht ausprobiert.

Ich weiß nicht, ob du zu Enterprise greifen würdest, aber FireDAC ist, im Verhältnis zu dbExpress, eine echte Offenbarung. Sage ich jetzt als jemand mit praktisch Null Datenbank-Praxiswissen.

Ich mache auch nur reine Windows-Sachen mit Delphi und dem C++ Builder. Warte noch zwei Tage bis zum 16., was XE6 bringen mag. Die VCL soll ja nicht ganz leer ausgehen, sagt man.

[Stevie]

Zitat:

Zitat von Der schöne Günther (Beitrag 1255572)

Ich habe das nie verstanden, warum die Dinger dann Generics genannt werden und nicht Templates? Denn das sind sie dann im Endeffekt doch, oder?

PS: Von Generics in .Net bzw. deren Unterschied zu C++ Templates habe ich keine Ahnung.

In C# wird der Code für einen Generic, wo der Typparameter ein Referenztyp ist, geshared. D.h. es spielt keine Rolle, ob du eine TList<TAffe> oder TList<TGiraffe> hast, weil beides ein Referenztyp ist. Der C++ Linker hingegen hat eine Optimierungsoption, die dafür sorgt, dass binär gleicher Code wieder rausgeworfen wird. Beides ist in Delphi nicht vorhanden, es wird pro generischer Typ der Code dupliziert.

Einzige Möglichkeit ist, sich da selber (je nach Art des Generics in sehr begrenztem Rahmen) zu behelfen, wie ich in Spring4D zum Beispiel mit den Listen getan habe.

[Tomski]

Guten Morgen zusammen,

ich möchte nochmals kurz auf das ursprüngliche Thema 'Größe der EXE-Datei" eingehen. Ich habe ein Projekt von mir von XE auf XE2 und gestern auf XE4 adaptiert. Der Größenunterschied bei gleichen Komponenten und gleichem Funktionsumfang ist frapierend, siehe folgende gerundete Größen.

XE = 6800 KB
XE2 = 28000 KB
XE4 = 32500 KB

Die vorgeschlagenen Compilerdirektiven "Wie von Daniel genannt" verkleinern bei XE4 gerade mal um 3 MB auf 29500 KB. Manche denken jetzt vielleicht was solls, die Größe interessiert doch niemand, Hauptsache es funktioniert. Wenn man aber aus Zeiten kommt als der Speicherplatz bzw. RAM noch knapp war fällt es einem schwer das klaglos zu akzeptieren und man stellt sich wohl die berechtigte Frage: Warum ist das so? Sind tatsächlich die Bibliotheken und Units so vergrößert worden oder wird lediglich aufgrund von Programmierzeitersparnis alles compiliert was nicht Niet und Nagelfest ist?

Danke für eure Antworten und noch einen schönen Sonntag wünsche ich Euch.