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