Größe Exe-Datei XE2 -> XE4

[Delphi-Laie]

Zitat von Bernhard Geyer:

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 von Sir Rufo:

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 von Daniel:

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.

[Stevie]

Zitat von Daniel:

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 von Sir Rufo:

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.

[UliBru]

Zitat von Daniel:

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 von UliBru:

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.

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

[Bernhard Geyer]

Zitat von Tomski:

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

Ich vermute du hast noch ein paar ungünstige Schalter gesetzt.
Unsere Hauptanwendung ist jetzt auch auf XE6-Stand.
Die Daten sind hier.

Delphi 6: 16,8 MB
Delphi XE6: 25,3 MB

Bis auf 2-3 kleiner Packages die jetzt nicht mehr benötigt werden (da XE6 das schon selbst mitbringt) ist der Quellcode nahezu identisch (bis noch auf einige $IFDEF UNICODE-Anweisungen)