Das Programm wird zu groß

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

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 😁

[IBExpert]

Zitat von 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 ��

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.

[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 von jaenicke:

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.

[TiGü]

Zitat von Uwe Raabe:

Zitat von jaenicke:

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 von TiGü:

Zitat von Uwe Raabe:

Zitat von jaenicke:

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?
2019-08-26 09_44_05-Window.png
Uwe sprach von Standard Delphi ohne 3rd-Party Erweiterungen, bzw. fragte welches Plugin das zur Verfügung stellt

[Uwe Raabe]

Zitat von TiGü:

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.