Erstellte Exe kleiner machen in D5Pro SP1

[Gremlin]

Howdy,


wir haben hier ein Problem mit dem Kompilieren und der Größe einer Delphi-Anwendung:

Beim Linken der Anwendung erscheint immer öfters die Meldung das zu wenig Arbeitspeicher
vorhanden wäre, wobei der Kompiliervorgang meist problemlos durchläuft und die Exe
trotzdem erstellt wird. Die IDE ist in diesem Fall nicht mehr zugänglich (nicht endende
Exceptions und D5 muss über den Task-Manager beendet werden).
Ein Debuggen der Anwendung ist somit nicht möglich.

Das Programm enthält ca. 500 Formulare (95% MDI) und hat eine Größe von ca. 40 MB.
Liegt darin die Ursache?

Frage:

- Woher kann der Linker-Fehler kommen?
- Ist es sinnvoll diese Anwendung als Packages aufzuteilen, wenn ja wie würde man
damit am besten vorgehen?
- Liegt das Problem an der Delphi-Version, bzw. würde ein Umstieg auf D7 oder höher
etwas bringen?


Grüsse von Gremlin

[Der_Unwissende]

HI,
interessant dürfte hier die Frage nach dem Entwicklungsrechner sein, wieviel Arbeitsspeicher ist denn vorhanden?

An sich sollte es nicht an der Größe deiner .exe liegen. Die kannst du auch nicht so ohne weiteres kleiner machen (die würde letztlich im Arbeitsspeicher wieder gleich groß sein). Was die Größe an sich angeht, so sind es häufig die Bilder, die eine .exe schnell wachsen lassen, versuch es mal ohne.
Das alles hat aber wenig mit der Fehlermeldung an sich zu tun. Woher die kommt kann ich dir nicht sagen, aber zwei Dinge dazu:

1. Das Compilieren und Linken dauert ein Weilchen und benötigt eine ganze Menge Ressourcen. Das kommt nicht von ungefähr, immerhin möchtest du die erstellte .exe einfach verwenden können. Dein Compiler übernimmt aber erstmal eine ganze Menge Aufgaben, z.B. wird der Code analysiert und optimiert. Das siehst du dann auch daran, dass du hier die ganzen Warnings bekommst. Dieser ganze Overhead der Analyse wird aut. im Speicher gehalten (während du compilierst), immerhin müssen hier auch Verweise aufgelöst werden. Die eigentliche Exe ist damit immer kleiner als eben diese ganzen Daten
2. Dein Debugger ist nochmal ein zusätzliches Programm, dass die Ausführung überwacht. Da gibt es dann noch mal eine ganze Menge zu tun, wenn es also einen Speicherfresser gibt, dann gehört der Debugger definitiv dazu. Läuft der, wird natürlich noch viel mehr Arbeitsspeicher belegt!

Das heißt nicht, dass du auf deinen Debugger verzichten solltest, die Frage ist, warum du so wenig Speicher zur Verfügung hast. Auf was für einem System entwickelst du denn? Ist der Virtuelle Speicher dyn. wachsend oder auf eine (möglicherweise zu kleine) max. Größe festgelegt?

Gruß Der Unwissende

[hoika]

Hallo,

zusätzlich zum Unwissenden.

40 MB ????
holla

also meine App hat ~ 700 Forms,
die ist ~ 20 MB gross (mit Debug-Info).

Sie wird jetzt allerdings kleiner,
seit ich ein paar Sachen in Frames auslagere.

Schaue dir aml deine DCU's an,
weclhe sind die größten?
Werden dort z.B. Bitmaps mehrfach verwendet?
Wenn ja, ab in ein Frame.


Heiko


PS:
Die Exe selber könnte man mit UPX verkleinern.
der Ram-Bedarf bleibt aber gleich (wird eigetlich sogar grösser,
weil die ganze Exe geladen wird).

[jbg]

Vielleicht sind ja auch "nur" die "TD32 Debug Infos" in die EXE kompliliert (Projektoptionen/Linker/[ ] Mit TD32-Debug-Info)

[Bernhard Geyer]

Kannst Du uns mal die genaue Fehlermeldung zeigen. Evtl. auch noch was du als Warnung/Hinweis während des übersetzens bekommst.

[RavenIV]

Wenn Deine exe ohne Debug-Infos wirklich so gross ist, solltest Du Dir Gedanken machen, ob man es nicht modularisieren kann.
- z.B. mit einigen DLLs (siehe Tutorial hier im Forum)
- oder mit verschiedenen exe, die sich gegenseitig laden

Auf jeden Fall solltest Du erreichen, dass nicht so viel RAM verblasen wird, es kommen ja sicher noch Daten des Programms hinzu.

[Gremlin]

Hi Leute,

erstmal vielen Dank für eure Hilfe.
Die Rechner sind wirklich grosszügig mit Speicher ausgestattet (ca. 1-1,5 GB Ram)
also wird es daran nicht liegen. Betriebssystem ist WindowsXP, Debuginfos, Warnungen,
Hinweise und TD32-Infos sind alle ausgeschaltet, Viren kann man auch vernachlässigen.

Mir kommt es so vor das zu wenig Speicher vorhanden ist, wie bei den früheren
BDE-Fehlermeldungen, wenn diverse Sessions gleichzeitig geöffnet waren und der
gemeinsame Speicher nicht ausreichend war oder - wer den Clipper noch kennt -
die Fehlermeldung mit dem "Memory overbooked". Nach dem compilieren wird gelinkt
und kurz vor dem Ende des Linkvorgang kommt dann öfters die Meldung:
"Fataler Fehler: Zu wenig Arbeitsspeicher". Manchmal erscheint auch eine Meldung
das eine Resource einer willkürlichen *.dfm nicht geöffnet werden kann. Diese Dateien
sind natürlich vorhanden. Dies ist dann oft der Punkt, bei dem man schnell noch
versucht die offenen Dateien zu speichern (save often, save early), da
Delphi ab diesem Zeitpunkt extrem kritisch reagiert.
Es kann sein, das die *.exe dann manchmal trotzdem erstellt wird.
Weiterhin kann es sein, das es mehrere Tage ohne jegliche Probleme funktioniert,
aber dann am nächsten Tag nach dem Einschalten des Rechners und dem ersten
Compiliervorgang überhaupt nicht mehr.

Ja es hört sich alles wirklich strange an, aber es ist einfach so.
Deshalb steht ja auch die Frage im Raum, ob es ein Fehler im Compiler/Linker
wäre und eine Umstellung auf D7 oder höher etwas bringen würde. Es ist eine
gewachsene Anwendung, die hier und dort suboptimal ist und man noch ein wenig
"aufräumen" könnte, aber ob dies einen wirklichen Durchbruch bringen würde,
höchstens einen Aufschub auf die nächste Obergrenze. Deshalb auch der Gedanke
zu Runtime-Packages und der Aufsplittung der einzelnen Module. Nur habe ich
ehrlich gesagt noch keine sehr grosse Erfahrung über die optimale Vorgehens-
weise beim Erstellen von Runtime-Packages.
Unter Win95/98 ist die Anwendung seit der Größe von ca. 33 MB nicht mehr
lauffähig (zb. "ungültiges Format der Anwendung")

Zu den Formularen: Es sind überwiegend relativ komplexe Formulare, die keine
oder sehr sehr wenig Grafiken enthalten (wenn dann nur kleine Glyphs). Jedoch
enthalten die Formulare überwiegend mindestens einen oder mehrere Grids (TopGrid),
Tabellen, Querys (mit statischen Feldlisten), viele TEdits und TLabels, mehrere
TButtons (alle von Raize-Components) und das wars dann auch schon.
Die grösste *.dfm ist ungefähr 500k gross (TextDFM-Format), verwendert werden
ungefähr 1200 Tabellen. Die Gesamtgrösse aller *.pas und *.dfm (TextDFM) ohne
Bibliotheken (8MB) ist in etwa 100 MB.
Es sind alle Formulare in der zweiten Uses im Hauptform aufgeführt und diese werden
über eine Funktion im Hauptformular aufgerufen a la:

class function <FormKlasse>.Execute(...)

Diese Methode prüft ob die Form schon vorhanden ist und erstellt/initialisiert
gegebenenfalls die Form:

<MDIForm> := <FormKlasse>.Create(Application);


Der Unterschied der optimierten zur Debug-Version ist gering, im Ganzen etwa
500 kb bis 1 MB.

Grafiken werden im allgemeinen fast keine und wenn dann sehr sehr sparsam
verwendet. SQL's werden im *.pas hinterlegt, vielleicht würde ein SQL-Dictionary
den Source entsprechend verringern. Beschreibungsfelder (Labels, Gridspalten)
werden zur Laufzeit übersetzt, das dürfte aber keine Rolle spielen.


@Heiko.

Leider sind die Forms an sich so unterschiedlich, das Frames nicht möglich sind.
Für die Buttonleiste (Neu, Ändern, Speichern,...) wird ein dynamischess Frame
verwendet, das sich automatisch an die Formulare (Ableitung von TForm) anlagert



Grüsse Gremlin