Das Programm wird zu groß

[NoName1]

Guten Tag,
Mein Programm, eine Vereinssoftware,wird zu groß. Es hat jetzt eine Größe vom 90.611.645
Das Programm hat eine Datenbank. Im Programm sind 2 Datenmodule enthalten.
Eines für Adressen usw. ein anderes nur für die Buchhaltung.
Beide Module werden mit dem Programmstart aktiviert.

Ich würde es gerne in 2 verschiedene Bereiche, -Hauptprogramm und Buchhaltung- trennen.

Meine Vorstellung dazu ist folgende:
Es muss immer das Hauptprogramm aufgerufen werden. Aus dem Hauptprogramm wird dann die Buchhaltung aufgerufen.

Fragen:
a) Wie stelle ich es an, dass die Buchhaltung auf die Adressen und evtl. andere Tabellen,
die im Modul -MoHauptprogramm- verwaltet werden, zugreifen kann? Mit der Trennung weiß das
eine Datenmodul ja nichts mehr vom anderen Datenmodul.

b) Macht die Trennung überhaupt Sinn?

c) Bringt die Trennung nicht mehr Arbeit als nötig?

d) Kann es auch anders gemacht werden?

Ich hoffe ich habe mich einigermaßen Verständlich Ausgedrückt
Vielen Dank für Eure prof. Hilfe im Voraus.

[Der schöne Günther]

Zitat:

b) Macht die Trennung überhaupt Sinn?

Das habe ich mich auch direkt gefragt - Was glaubst du dadurch eigentlich gewonnen zu haben?

[Bernhard Geyer]

90 MB Exe-Grösse?
Wenn du jetzt daran nicht 100 Mannjahre Entwicklung reingesteckt hast, tippe ich auf folgende Ursachen

1, Du kompilierst die Exe mit Debug-Info.
Schau mal bei den Linker-Settings nach. Werden oft nicht beachtet.

2, Du verwendest sehr viele Bilder im BMP-Format. Besser wäre hier PNG oder bei Foto besser komprimierte JPG.

3, Du hast zu viel 3th-Party Bibliotheken im Einsatz. Mehr als 10 wären ein Indiz

[p80286]

90 MB ? sind da die Daten Teil der exe geworden?
Selbst wenn mehr als 100 Abfragen in beiden DM stecken würden, spricht aus meiner Sicht nichts gegen ein Modul für beide Funktionen. Ggf solltest Du uns einmal Einblick in die Sourcen gewähren.

Gruß
K-H

[Neumann]

Ich komme bei 1,6 Millionen Programmzeilen incl. Fremdkomponenten die mit compiliert werden so auf 40 MB. Und ich habe etliche Fremdkomonenten drin wie Jedi,einige TMS Cport, Fastreport, Mydac,Ibdac um nur die wichtigsten zu nennen

[IBExpert]

Warum glaubst du das es zu groß ist? Für was? Hast du nur eine 100MB Festplatte im Einsatz?

Eine Exe wird unter Windows nicht ohne Grund komplett in den Speicher geladen, daher
kann es durchaus sein, das deine exe nur zu 10-20 MB im normalen Ablauf überhaupt vom
Datenträger gelesen wurde. Kleinere Exe ist nicht automatisch schneller, aufteilen in
mehrere Exe ist eher negativ als positiv in Bezug auf Performance.

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.

[dummzeuch]

Zitat:

Zitat von IBExpert (Beitrag 1443112)

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.

In den meisten Fällen ergibt die Verwendung von UPX keinen Vorteil aber diverse Nachteile. UPX-Executables müssen z.B. komplett in den Speicher geladen werden und werden dann in die Swap-Datei ausgelagert statt Pages bei Bedarf einfach aus dem Exectutable neu zu laden (wobei letzteres auch ein Vorteil sein kann.)

Aber 90 MB Executable-Größe kommt mir auch extrem viel vor. Meine sind in der Regel <20 MB, und das halte ich schon für groß.

[Der schöne Günther]

Gab es nichtmal irgendein Tool das anhand der erzeugten DCU-Dateien zeigen konnte woher der Speicherverbrauch kommt? Zumindest welche Units "wie dick" werden?

Hat mir einmal sehr geholfen als jemand eine 25 MB große Bitmap in einem DFM-Formular untergebracht hat 😁

[jaenicke]

Unsere Anwendungen haben auch durchaus über 100 MiB, aber da stecken auch deutlich 7 stellige Mengen an Codezeilen drin, wenn ich alle Fremdkomponenten mitzähle.

Wenn man solche Anwendungen nun z.B. in DLLs aufteilt, kann es sein, dass diese auch deutlich kleiner sind. Das muss aber nicht so sein. Wenn man die gleichen Fremdkomponenten und eigenen Quelltexte in beiden Teilen nutzt, hat man am Ende zwei oder mehr nur wenig kleinere DLLs oder Anwendungen.

Insofern macht es keinen Sinn da nun viel Aufwand hineinzustecken ohne vorher genau zu schauen weshalb die Anwendung so groß ist und ob man das offenbar dadurch entstehende Problem (?) nicht auch anders lösen kann und die Anwendung so bleiben kann. Ein erster Fingerzeig ist die Analyse über Projekt --> Analyze project ..., womit du einen Überblick über die eingebundenen Units und deren Größe bekommst. (@Der schöne Günther: Das meinst du vermutlich.)

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1443116)

Ein erster Fingerzeig ist die Analyse über Projekt --> Analyze project ..., womit du einen Überblick über die eingebundenen Units und deren Größe bekommst.

Und das stellt welches PlugIn zur Verfügung? Standard Delphi ist das offenbar nicht.

[IBExpert]

Zitat:

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

Gab es nichtmal irgendein Tool das anhand der erzeugten DCU-Dateien zeigen konnte woher der Speicherverbrauch kommt? Zumindest welche Units "wie dick" werden?

Hat mir einmal sehr geholfen als jemand eine 25 MB große Bitmap in einem DFM-Formular untergebracht hat ��

Man bekomt meistens einen ganz guten Eindruck davon, was da so viel platz belegt, wenn man da mal einen Delphi Decompiler über die exe drüberjagt. Das Ergebnis ist im Gegensatz zu so machen .NET Decompile für die Weiterbenutzung in Delphi fast unbrauchbar, aber die Aufteilung und ggf dabei erzeugten dfm zeigen ziemlich klar, was da am Ende in der exe zB via dfm eingebunden ist. die decompiler, mit denen ich so was mal gemacht hab, haben alle dfm inhalte recht gut extrahiert und auch da war bei einem Kundenprojekt eine Imagelist als Verursacher schnell lokalisiert, die komplett in der dfm enthalten war und nicht zur Laufzeit geladen wurde.

Der große Vorteil auf diesem weg via Decompiler ist, das du nicht erst durch deine Sourcen durchgehen musst und jeden möglichen Compilerschalter im Kopf haben musst, der ziemlich viel Kram entweder integriert oder auch ignoriert. Was der decompiler findet ist am ende auch drin.

[TiGü]

Zitat:

Zitat von Uwe Raabe (Beitrag 1443118)

Zitat:

Zitat von jaenicke (Beitrag 1443116)

Ein erster Fingerzeig ist die Analyse über Projekt --> Analyze project ..., womit du einen Überblick über die eingebundenen Units und deren Größe bekommst.

Und das stellt welches PlugIn zur Verfügung? Standard Delphi ist das offenbar nicht.

Sicher?
Menü Project -> Analyze project XYZ.dproj.
Zwischen Information for XYZ und Compile All Projects

[Schokohase]

Zitat:

Zitat von TiGü (Beitrag 1443262)

Zitat:

Zitat von Uwe Raabe (Beitrag 1443118)

Zitat:

Zitat von jaenicke (Beitrag 1443116)

Ein erster Fingerzeig ist die Analyse über Projekt --> Analyze project ..., womit du einen Überblick über die eingebundenen Units und deren Größe bekommst.

Und das stellt welches PlugIn zur Verfügung? Standard Delphi ist das offenbar nicht.

Sicher?
Menü Project -> Analyze project XYZ.dproj.
Zwischen Information for XYZ und Compile All Projects

Sicher?
Anhang 51587
Uwe sprach von Standard Delphi ohne 3rd-Party Erweiterungen, bzw. fragte welches Plugin das zur Verfügung stellt

[Uwe Raabe]

Zitat:

Zitat von TiGü (Beitrag 1443262)

Sicher?
Menü Project -> Analyze project XYZ.dproj.
Zwischen Information for XYZ und Compile All Projects

Ziemlich sicher! An der Stelle stehen bei mir die Methodentoxizitäts-Metriken.

Erstes Indiz: es ist in Englisch (gut, das könnte auch euer Setup sein)
Zweites Indiz: es wird in der Hilfe nicht erwähnt: Menü Projekt
Drittes Indiz: siehe Screenshot

[TiGü]

Ach schau, da guck...das gehört zur JCL. :shock:

[TiGü]

Zitat:

Zitat von Uwe Raabe (Beitrag 1443264)

Erstes Indiz: es ist in Englisch (gut, das könnte auch euer Setup sein)

OT: Die Entwicklungsumgebung immer auf Englisch, es ist sonst nur zumeist schlimmer (Übersetzungs-)-Augenkrebs.

Kleines Schmankerl dazu: https://github.com/danielauener/git-auf-deutsch :-D

[buddyman83]

Zitat:

Zitat von IBExpert (Beitrag 1443112)

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.

[jaenicke]

Zitat:

Zitat von TiGü (Beitrag 1443272)

Ach schau, da guck...das gehört zur JCL. :shock:

Tut es, ja, aber da die meistens eh installiert ist...
Aber das hatte ich vergessen zu erwähnen, ja. :oops:

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

[Stevie]

Seit XE6 bringt

Delphi-Quellcode:

{$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:

Zitat von Stevie (Beitrag 1443676)

Seit XE6 bringt

Delphi-Quellcode:

{$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:

Zitat von samso (Beitrag 1443784)

Zitat:

Zitat von Stevie (Beitrag 1443676)

Seit XE6 bringt

Delphi-Quellcode:

{$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%.

Delphi-Quellcode:

{$WEAKLINKRTTI ON}

wohlmöglich, die

Delphi-Quellcode:

$RTTI

Direktive allerdings hat nur Auswirkung auf Typen in derselben Unit.

[samso]

Zitat:

Zitat von Stevie (Beitrag 1443815)

Delphi-Quellcode:

{$WEAKLINKRTTI ON}

wohlmöglich, die

Delphi-Quellcode:

$RTTI

Direktive allerdings hat nur Auswirkung auf Typen in derselben Unit.

Das ist bei mir nicht so. {$WEAKLINKRTTI ON} hat bei mir keine Auswirkung auf die Programmgröße. Bei {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])} wird das Programm 10% kleiner (nur Release und nur Win32 getestet).

[Stevie]

Zitat:

Zitat von samso (Beitrag 1443818)

Zitat:

Zitat von Stevie (Beitrag 1443815)

Delphi-Quellcode:

{$WEAKLINKRTTI ON}

wohlmöglich, die

Delphi-Quellcode:

$RTTI

Direktive allerdings hat nur Auswirkung auf Typen in derselben Unit.

Das ist bei mir nicht so. {$WEAKLINKRTTI ON} hat bei mir keine Auswirkung auf die Programmgröße. Bei {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])} wird das Programm 10% kleiner (nur Release und nur Win32 getestet).

Wie bereits gesagt, vielleicht, wenn du es per include oder direkt in die jeweiligen Units packst, nicht aber wenn nur einzig und allein in der dpr ist, außer dort befinden sich auch Klassen, die dann komplett oder teilweise rausfliegen und sich ggf kaskadieren, da dann der Smartlinker seine Arbeit machen kann.
Denn genau dann würde man sich ggf Klassen zerreißen, bei denen RTTI notwendig ist, wenn von anderen Units aus $RTTI ausgeschalten wird. Wenn der Scope dieser Direktive nur unitweit ist, kann man genau kontrollieren, wo man explizit auf RTTI verzichten kann. Alles andere wäre die Rückkehr des in XE6 gefixten Bugs und sehr unratsam, es weiter zu empfehlen/benutzen.

[samso]

Zitat:

Zitat von Stevie (Beitrag 1443815)

Delphi-Quellcode:

{$WEAKLINKRTTI ON}

wohlmöglich, die

Delphi-Quellcode:

$RTTI

Direktive allerdings hat nur Auswirkung auf Typen in derselben Unit.

Stimmt, Du hast recht. Ich nehme alles zurück :oops: Es ist der {$WEAKLINKRTTI ON}-Schalter der die 10% bringt. Sorry!

[Rolf Frei]

Zitat:

Zitat von NoName1 (Beitrag 1443631)

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:

Zitat von Rolf Frei (Beitrag 1443963)

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]

Zitat:

Zitat von Uwe Raabe (Beitrag 1443979)

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.

Doch, ist und sollte es. Schau dir mal an, wie viel nutzloser Klump in einer Exe landet, wenn du nur ne VCL Anwendung machst und da mal nen QuantumGrid drauf packst, oder eine leere FMX Anwendung. Mehrere Megabyte durch duzende verschiedenen TList<...> obwohl sie ja die meist gebrauchten Methoden seit XE7 inlined haben. Aber da für die ganzen Collections nunmal RTTI an ist, werden die alle in die Exe gezogen. Ich hab bisher nicht genau analysiert, wie die letztlich angeordnet sind, aber der Instruction Cache der CPU wird sich bestimmt nicht drüber freuen.

[Rollo62]

[QUOTE=Stevie;1443980]

Zitat:

Zitat von Uwe Raabe (Beitrag 1443979)

duzende verschiedenen TList<...> obwohl sie ja die meist gebrauchten Methoden seit XE7 inlined haben. Aber da für die ganzen Collections nunmal RTTI an ist,

In Spring4D wird ja auch die System.Generics.Collections eingebunden, also wäre das Problem mit TList<> dort auch akut, oder gibt es eine Alternative dazu die sich mit Spring4D verträgt ?

[Rolf Frei]

Zitat:

Zitat von Uwe Raabe (Beitrag 1443979)

Zitat:

Zitat von Rolf Frei (Beitrag 1443963)

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.

Ja das weiss ich ja. Nur hat eben der Schalter im DPR keine Auswirkung auf die gelinkten Delphi dcu's sondern nur auf die eigenen Units die neu kompiliert werden.

[Stevie]

Zitat:

Zitat von Rollo62 (Beitrag 1443990)

Zitat:

Zitat von Stevie (Beitrag 1443980)

duzende verschiedenen TList<...> obwohl sie ja die meist gebrauchten Methoden seit XE7 inlined haben. Aber da für die ganzen Collections nunmal RTTI an ist,

In Spring4D wird ja auch die System.Generics.Collections eingebunden, also wäre das Problem mit TList<> dort auch akut, oder gibt es eine Alternative dazu die sich mit Spring4D verträgt ?

Spring4D nutzt nur an einigen wenigen Stellen System.Generics.Collections und zwar dort, wo man aufgrund des ich nenns mal "Henne-Ei"-Problems nicht die Spring.Collections nutzen kann, z.B. in der Spring.pas. Zudem sind schon seit langem die ganzen Collections eigene Implementierungen (früher waren es alles nur Wrapper um die System.Generics.Collections Klassen) - mit 2.0 wurde die letzte dieser (das Dictionary) abgelöst.

Zudem hab ich für 2.0 massiv daran gearbeitet, eben diesen Code Bloat zu bekämpfen - RTTI abgeschaltet, wo es geht, interne Architekturen umgestellt und einige Tricks, um identische Generics nicht zu duplizieren. Dieser wirkt sich nämlich nachweisbar nicht nur auf die Größe der Binary aus, sondern auch auf die Compilezeit und den Speicherverbrauch des Compilers - mal ein paar Zahlen auszugsweise: im Vergleich 1.2.2 zu 2.0 (Stand alpha.2) haben sich die Compilezeiten unter Win32 bis zu viermal verbessert - ein Referenzprojekt was ich dazu nutzte ging von über 60 Sekunden für einige 100K LoC wo eine Menge von Generics genutzt wurden auf unter 15 Sekunden und die Binarygröße hat sich in ähnlicher Größenordnung verringert (natürlich je nach Code und Anwendung unterschiedlich).

Mehr zu der ganzen Thematik werd ich dieses Jahr auf der EKON erzählen.

[Rollo62]

Danke für die info, gut zu wissen.