Debug und Release liefert nahezu gleichgroße Exe-Dateien

[Bernhard Geyer]

Du musst auch die Einstellungen im Bereich Linker anschauen.
Da gibt's einige Einstellungen die eine Exe sehr viel größer machen (aber auch nötig sind damit z.B. AQTime Laufzeitmessungen durchführen kann) und bei neu angelegten Projekten in der Debug-Konfiguration standardmäßig angewählt sind.
Diese großen Unterschied bekommst du auch unter alten Delphis hin wenn du die TD32-Debug-Infos aktivierst.

[Hobbycoder]

Das einzige, was dort aktiviert ist (wie gesagt, Default und nicht von mir geändert) ist Debug-Informationen und das solle ja so sein. Beim Map-Datei steht detailliert, aber das ist ja sowieso eine separate Datei.

Was ich noch ändern könnte wäre unter Compilieren - Debug-Informationen. Dort steht Debug-Informationen, ich könnte aber auf "begrenzte Debug-Information" umschalten. Aber es ist ja Default und ich weiß nicht, welche Einschränkungen ich mir damit beim Debuggen einhandele.

Ich meine, wenn die Debug-EXE so groß sein soll/muss, dann ist es halt so. Ist ja nicht so, dass es mich wesentlich stört. Ich war nur etwas erschrocken.
Meine Frage im Eröffnungsthread zielt ja eigentlich darauf ab, dass ich nicht eine EXE-Datei weitergeben will, die mehr Daten enthalten (also Debug-Informationen) als für die Ausführung beim Anwender notwendig ist.

Durch das erzeugen der neuen Projektdatei sieht es für mich jedoch eher so aus, dass in meiner ursprünglichen Debug-EXE keine Debug-Informationen drin waren, jedoch das Debugging ohne Probleme funktionierte.
Ich hätte durch das Neuerzeugen der Projektdatei erwartet, dass die Release-EXE kleiner wird, und die Debug-EXE so bleibt. Stattdessen ist es umgekehrt. Und das hat mich gewundert.

[Bernhard Geyer]

Wie schon geschrieben gibt es mehrer Einstellungen für Debug-Infos.

Zum Debuggen in der IDE brauchst du nur die Debug-Einstellung auf die Compiler-Seite. Dann wird die Exe nur geringfügig größer.
Den Schalter auf der Linker-Seite brauchst du z.B. um mit AQTime zu arbeiten. Und dieser Schalter macht (wie auch schon zu Delphi 6-Zeiten die Exe sehr viel größer).
Da hat sich nichts grundlegendes in den letzten 20 Jahren geändert.

Und wenn deine alte Debug-Exe klein war dann hatte Sie nur auf der Compilerseite den Schalter gesetzt aber nicht auf Linker-Seite.

Und deine Release-Exe bekommst du etwas kleiner mit {$WEAKLINKRTTI ON} in der dpr-Datei.
Dann darfst du aber nicht auf automatisch erzeugte erweiterte RTTI-Infos setzen in deinem Quellcode.

[EWeiss]

Exe Größe Hin oder Her ich meine das in Delphi Kompilierte Dateien unnötig aufgebläht sind.
Ich Kompiliere eine DLL..

Jetzt frage ich mich ernsthaft was haben da ein Icon\IconGroup, Cursor\CursorGroup und andere dinge zu suchen?
Die werden weder benötigt noch erfüllen sie irgendeinen zweck und sind nicht von Nöten damit meine DLL funktioniert.

Was soll das also? Und warum kann man diese NICHT benötigen Dinge aus dem Kompilat nicht ausschließen.

EDIT:
Zudem sind die Package Informationen für mich ein Ansatz um das Kompilat zu dekompilieren.
Warum muss diese öffentlich in einer DLL durch das Kompilieren mit eingebunden werden.


gruss

[himitsu]

Das liegt daran, dass der Compiler da nichts optimieren kann, da er nicht wissen kann ob eine Ressource benötigt wird, also wird alles einkompiliert, was in irgendeiner Unit inkludiert wurde.
Bei Klassen und Funktionen ist das was Anderes ... wird die nicht verwendet, sie sind nicht public (im Interface) und es handelt sich nicht um ein Package, dann kann sie einfach vom Linker weggelassen werden.

[EWeiss]

Zitat von himitsu:

Das liegt daran, dass der Compiler da nichts optimieren kann, da er nicht wissen kann ob eine Ressource benötigt wird, also wird alles einkompiliert, was in irgendeiner Unit inkludiert wurde.
Bei Klassen und Funktionen ist das was Anderes ... wird die nicht verwendet, sie sind nicht public (im Interface) und es handelt sich nicht um ein Package, dann kann sie einfach vom Linker weggelassen werden.

Ich verwende wie gesagt weder Icons noch Cursor noch irgendwelche Packages also warum werden meine Units
durch die Package Info öffentlich gemacht.

Sie haben keinen Nutzen in irgendeiner Form.

Zitat:

da er nicht wissen kann ob eine Ressource benötigt wird

Nein ?
Ich kann sie doch explicit angeben in dem ich sie zu meinem Projekt addiere.
Wenn ich keine hinzufüge sollte auch keine zum Kompilat addiert werden.. Meine Meinung.
Wie man im Shot sehen kann den ganzen Müll (sorry) bis auf die Versions Info brauche ich einfach in der DLL nicht.

gruss

[himitsu]

Weil das Zeugs sich in vielen VCL-Units versteckt, welche du verwendest.
Und die PackageInfo ist z.B. für die RTTI mit drin.
DVCLAL sind die Lizenzinfo deiner Delphi-Version/Edition. (darüber wird geregelt ob und was in deinem Kompiilat verwendet werden darf ... z.B. falls DataSnap einkompiliert ist, aber dafür nur eine Starter/Prof verwendet wurde)

Nichtgenutztes weglassen geht halt nicht bei Ressourcen.

Bei Ressourcen und RTTI kann man auch indirekt drauf zugreifen, womit es da keine erkennbare Verbindung gibt.
Fazit: Der Compiler/Linker muß alles mit rein nehmen, falls es doch gebraucht wird.

[Bernhard Geyer]

Zitat von EWeiss:

Exe Größe Hin oder Her ich meine das in Delphi Kompilierte Dateien unnötig aufgebläht sind.
Ich Kompiliere eine DLL..

Jetzt frage ich mich ernsthaft was haben da ein Icon\IconGroup, Cursor\CursorGroup und andere dinge zu suchen?

Also unsere DLLs haben kein Icon/IconGroup. Wenn du diese nicht benötigst dann deaktiviere/lösche sie doch aus dem Projekt.
Cursor\CursorGroup ist drin. Liegt halt an den VCL-Komponenten welche diese einbinden. Wenn du diese nicht benötigst, sorge durch passende Uses-Anweisung das sich nicht gezogen werden.

Zitat von EWeiss:

Die werden weder benötigt noch erfüllen sie irgendeinen zweck und sind nicht von Nöten damit meine DLL funktioniert.
Was soll das also? Und warum kann man diese NICHT benötigen Dinge aus dem Kompilat nicht ausschließen.

Hab jetzt in unserer kleinesten DLL (ohne VCL) geschaut. Dort ist weder das eine noch das andere drin.
Also macht der Compiler/Linker nichts was nicht durch das eigene Handeln (uses-Anweisung) verschuldet wäre.

Zitat von EWeiss:

Zudem sind die Package Informationen für mich ein Ansatz um das Kompilat zu dekompilieren.
Warum muss diese öffentlich in einer DLL durch das Kompilieren mit eingebunden werden.

RTTI und Co. macht es nun mal nötig das diverse Infos in solchen gemeinsam genutzten DLLs (was anderes sind die BPLs ja nicht) zur verfügung gestellt werden.
Stören diese, dann arbeite ohne BPLs.

[EWeiss]

Zitat:

Wenn du diese nicht benötigst dann deaktiviere/lösche sie doch aus dem Projekt.

Wie?
Denn ich habe schon gesagt das die DLL keine *.dfm Unit eingebunden hat.

Zitat:

Hab jetzt in unserer kleinesten DLL (ohne VCL) geschaut. Dort ist weder das eine noch das andere drin.

Ich verwende kein VCL.
Diese DLL verwendet nur Header von Diversen Plugin Typen welche dann benutzt werden um mit diesen zu kommunizieren.

Zitat:

Stören diese, dann arbeite ohne BPLs.

Wie kommst du darauf das ich BPLs verwende tue ich nicht.
Und wenn dann müssen sie irgendwo im Suchpfad liegen.

gruss

[Bernhard Geyer]

Zitat von EWeiss:

Zitat:

Wenn du diese nicht benötigst dann deaktiviere/lösche sie doch aus dem Projekt.

Wie?
Denn ich habe schon gesagt das die DLL keine *.dfm Unit eingebunden hat.

Solche Ressourcen sind nicht an dfm-Units gebunden.

Zitat:

Wie kommst du darauf das ich BPLs verwende tue ich nicht.

Sehe gerade es geht um die PACKAGEINFO-Bereich.
Den Packt Delphi auch in DLLs auch wenn es nicht immer nötig wäre.
Bei BPLs ist es nötig um um feststellen zu können wenn eine Pas-Datei sonst mehrfach geladen würde was ja dem Highlander-Prinzipg bei gemeinsam genutzter Runtime (Dll.TObject = Exe.TObject) nicht sein darf.