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.