Das Programm wird zu groß

[buddyman83]

Zitat von IBExpert:

Wenn es kleiner sein soll, dann lass mal upx da drüber laufen, aber außer das die
Datei danach kleiner ist, ergibt auch das wenigVorteile.

Es ergibt sogar viele Nachteile, denn mit upx komprimierte Programme werden gerne von Virenscannern als Verdächtig angezeigt.
Das führt gerade bei technisch weniger versierten Benutzern/Kunden nur zu unangenehmen Gesprächen.

Meine Programme werden seitdem ich den "Beziers"-Skin von DevExpress als Standard verwende auch 30-40MB groß.
Habe aber bisher noch keine Probleme feststellen können.

[Rolf Frei]

Was ist denn das Prolbem mit der Grösse? Wenn du aus einer Anwendung zwei machen willst, in denen du dann die selben Komponenten nutzt, wirst du danach vermutlich 2 Anwendungen mit 80 MB anstatt nun einer mit 90 MB haben.


Platziere doch mal folgende rooten Zeilen in deinem DPR und schaue was dabei rauskommt. Die Exe müsste dadruch einiges kleiner werden.

program MyApp;

{$WEAKLINKRTTI ON}
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}

uses
Forms,
Windows,
FForm1 in 'FForm1.pas' {Form1};

{$SetPEFlags IMAGE_FILE_RELOCS_STRIPPED}

{$R *.res}

begin
Application.Initialize;
Application.CreateForm(TForm1, Form1);
Application.Run;
end.

[NoName1]

Rolf Frei,
ich habe beides eingebunden, kompiliert und siehe da das Programm ist kleiner geworden.
Beim Nachschauen was diese {$WEAKLINKRTTI ON} Compiler-Direktive bedeutet bin ich
auf diesen Link in der DP gestoßen: https://www.delphipraxis.net/183645-...klinkrtti.html

Scheinbar birgt das Hinzufügen dieser Compiler-Direktiven auch Risiken mit sich, wenn mit Datenbanken
gearbeitet wird.

Ich werde die EXE-Datei einfach so lassen wie sie ist. Die Vereinsverwaltung ist halt auch sehr umfangreich.
Trotzdem vielen Dank an allen für die Diskussion und die Hilfe.

[Rolf Frei]

Zitat von NoName1:

Rolf Frei,
ich habe beides eingebunden, kompiliert und siehe da das Programm ist kleiner geworden.
Beim Nachschauen was diese {$WEAKLINKRTTI ON} Compiler-Direktive bedeutet bin ich
auf diesen Link in der DP gestoßen: https://www.delphipraxis.net/183645-...klinkrtti.html

Scheinbar birgt das Hinzufügen dieser Compiler-Direktiven auch Risiken mit sich, wenn mit Datenbanken
gearbeitet wird.

Ich werde die EXE-Datei einfach so lassen wie sie ist. Die Vereinsverwaltung ist halt auch sehr umfangreich.
Trotzdem vielen Dank an allen für die Diskussion und die Hilfe.

Nur so aus Interesse: Wieviel macht es denn aus?

Wenn du kein Databinding nutzt, sondern die meinses erachtens eh besseren und traditionellen TDatasource/TDatasets, sollte das kein Problem sein. Ich nutze diese Flags schon seit langer Zeiet und habe überhaupt kein Problem damit und ich nutze sehr viel DB Sachen, aber eben ohne das langsame RTTI basierende Databinding.

[jaenicke]

Wir benutzen die RTTI an vielen Stellen, das hat aber bei uns nichts mit Datenbanken zu tun.

[Rolf Frei]

Das Flag hat eh nur Auswirkung auf neu kompilierten, also eigenen Code. Die ganze Delphi Library wird ja nicht neu kompiliert und daher wird das da auch keine Auswirkung haben. Die Delphi DCU's sind ja so kompiliert, dass RTTI geht. Würde man die ganze Library noch neu kompilieren, würde die Exe Grösse nochmals massiv verkleienert. Mit der Einführung der neuen RTTI sind ja leider auch die exes in der Grösse explodiert und wenn man selber garkein RTTI braucht ist das schon sehr ärgerlich.

[Uwe Raabe]

Zitat von Rolf Frei:

Die ganze Delphi Library wird ja nicht neu kompiliert und daher wird das da auch keine Auswirkung haben. Die Delphi DCU's sind ja so kompiliert, dass RTTI geht. Würde man die ganze Library noch neu kompilieren, würde die Exe Grösse nochmals massiv verkleienert. Mit der Einführung der neuen RTTI sind ja leider auch die exes in der Grösse explodiert und wenn man selber garkein RTTI braucht ist das schon sehr ärgerlich.

Allerdings wird innerhalb der Delphi-DCUs selbst mittlerweile immer mehr RTTI wirklich benutzt. So ist das gesamte Component-Streaming in System.Classes ohne RTTI gar nicht mehr voll funktionsfähig (und wer will schon auf System.Classes verzichten). Insofern ist es auch keine Option mehr, in den Standard-DCUs das RTTI abzuschalten.

[Stevie]

Seit XE6 bringt {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])} in der dpr genau gar nix mehr - dass es vorher funktioniert hat, war ein Bug, denn der scope der $RTTI Direktive ist nur unit weit (vorher hat er sich global verhalten).

Um ggf eine Idee zu bekommen, was genau in der exe so viel Platz verbraucht, kann man mal die map Datei in MapFileStats öffnen und schauen.

[samso]

Zitat von Stevie:

Seit XE6 bringt {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])} in der dpr genau gar nix mehr - dass es vorher funktioniert hat, war ein Bug, denn der scope der $RTTI Direktive ist nur unit weit (vorher hat er sich global verhalten).

Das scheint aber vom Benutzerprofil abzuhängen. Bei mir (Delphi 10.1) bringt es immerhin eine Einsparung von 10%.

[Stevie]

Zitat von samso:

Zitat von Stevie:

Seit XE6 bringt {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])} in der dpr genau gar nix mehr - dass es vorher funktioniert hat, war ein Bug, denn der scope der $RTTI Direktive ist nur unit weit (vorher hat er sich global verhalten).

Das scheint aber vom Benutzerprofil abzuhängen. Bei mir (Delphi 10.1) bringt es immerhin eine Einsparung von 10%.

{$WEAKLINKRTTI ON} wohlmöglich, die $RTTI Direktive allerdings hat nur Auswirkung auf Typen in derselben Unit.