Größe der Exe reduzieren

[smudo]

Hallo,

die Exe zu einem meiner Projekte ist mittlerweile sehr groß geworden (12MB).
Ich habe nun versucht, die Größe zu reduzieren, indem ich Laufzeit-Packages verwende.
Ich habe beispielsweise vcl;rtl;vclx ausgelagert, sowie einige Jedi-Packages (jcl;jclvcl;JvXPCtrlsD7R) und damit schon stattliche 4MB gespart.

Meine Fragen:

• Wie reduziert ihr die Größe eurer Exe-Datei?
• Wie kann man ermitteln, welche weiteren Packages besonders groß sind, um sie auszulagern?
• Gibt es andere Wege, als das Auslagern der Packages?

Vielen Dank schon mal im Voraus
René

[Phoenix]

Zitat:

Zitat von smudo

Meine Fragen:

• Wie reduziert ihr die Größe eurer Exe-Datei?

Kurz und knapp: Gar nicht.

Eine Große .exe ist nichts schlimmes. 12 MB passen locker in jeden Arbeitsspeicher.
Um Downloadgröße zu sparen packe ich die exen mit effektiven Kompressionsmethoden. Werden die Programme von einem Netzlaufwerk gestartet komprimiere ich sie mit UPX um Netzlast zu vermeiden, aber um das Deployment zu vereinfachen benutze ich keine ausgelagerten Laufzeit-Packages. Das gibt nur Probleme wenn man Software die unterschiedliche Versionen eines Packages benötigt nebeneinander ausliefern muss.

[Bernhard Geyer]

Das Auslagern der packages spart nur bei der Exe-Größe. Deine Anwendung wird aber immer noch genausoviel Speicher (bzw. mehr) benötigen.

Meine Vorschläge sind:

- Kontrolle ob nicht "tote" Units noch in den Usesanweisungen stehen
- BMPs, JPEGs etc. in eine Zentrale Unit auslagern und dort gemeinsam verwenden
- Komponentenwildwuchs beseitigen. D.h. 2-3 Packagesammlungen definieren die verwendet werden und nicht für jede x-Beliebiges GUI-Control wieder eine Kompo aus einer anderen Packagesammlung verwenden.

[smudo]

Zitat:

Zitat von Phoenix

Kurz und knapp: Gar nicht.

Ich sollte Hellseher werden - irgendwie wusste ich, dass sowas als erste Antwort kommt. :zwinker:
Die Kunden, welche die Software benutzen, haben teilweise sehr langsame und instabile Leitungen, da kam es schon öfters zu unangenehmen Verbindungsabbrüchen beim Update. Deshalb würde ich gern bei meiner Frage bleiben.

Das ausgelagerte Packages riskant sind, so wie du es beschrieben hast, leuchtet ein. Solange die Packages im Programmverzeichnis liegen, sollte das aber trotzdem funktionieren.

Zitat:

Zitat von Bernhard Geyer

Kontrolle ob nicht "tote" Units noch in den Usesanweisungen stehen

Das hab ich angefangen, ist aber äußerst mühselig. Lässt sich das irgendwie automatisieren?

Zitat:

Zitat von Bernhard Geyer

BMPs, JPEGs etc. in eine Zentrale Unit auslagern und dort gemeinsam verwenden

Verwende ich kaum (außer Icons in einer zentralen Imagelist)

Zitat:

Zitat von Bernhard Geyer

Komponentenwildwuchs beseitigen. D.h. 2-3 Packagesammlungen definieren die verwendet werden

Wir verwenden als zusätzliche Komponenten fast ausschließlich die Jedis, aber darin sind ja schon Unmengen von Packages enthalten.

Meine Frage bleibt: Wie kann ich meine existierende Datei möglichst automatisiert oder zumindest mit unterstützenden Tools verkleinern? Ich habe beispielsweise mit dem PEViewer die Packageinfo ausgelesen - kann aber daraus noch nicht die entscheidenden Schlüsse ziehen.

[Phoenix]

Zitat:

Zitat von smudo

Zitat:

Zitat von Bernhard Geyer

Kontrolle ob nicht "tote" Units noch in den Usesanweisungen stehen

Das hab ich angefangen, ist aber äußerst mühselig. Lässt sich das irgendwie automatisieren?

Icarus Uses List Analyzer ist Dein Freund :)

[Bernhard Geyer]

Zitat:

Die Kunden, welche die Software benutzen, haben teilweise sehr langsame und instabile Leitungen, da kam es schon öfters zu unangenehmen Verbindungsabbrüchen beim Update. Deshalb würde ich gern bei meiner Frage bleiben.

Stellst du das Update denn auch als Komprimiertes ZIP/7z bereit?

Zitat:

Zitat von smudo

Das hab ich angefangen, ist aber äußerst mühselig. Lässt sich das irgendwie automatisieren?

http://www.peganza.com/#ICARUS

[SirThornberry]

Du könntest für dein Problem, es noch so machen wie Adobe etc. Einen Miniinstaller zur Verfügung stellen welcher die eigentlichen Daten lädt. Wenn die Verbindung dann abbrichst lädst du einfach an der unterbrochenen Stelle weiter. Die Kunden könnten zwar auch gleich einen Downloadmanager nehmen der die gleichen Möglichkeiten bietet aber ihnen das so bereit zu stellen ist meist einfacher.

[smudo]

Zitat:

Zitat von Phoenix

Icarus Uses List Analyzer ist Dein Freund

Danke für den Tipp, den werde ich jetzt erstmal testen...

[Dezipaitor]

hast du in den Compilereinstellungen alle Debug Kreuze ausgeschaltet? Danach muss man dann das Projekt neu erzeugen (nicht neu compilieren!).

Du kannst Updates auch einfach über Protokolle verschicken, die eine Fortsetzung nach Abbruch ermöglichen (FTP, HTTP). Zudem ist ja packen möglich.

Die EXE in Delphi kann man schnell kleiner machen, indem man gleich garnicht VCL verwendet. Aber der Erstellungs- und WartungsAufwand wächst dann natürlich, weil große nonVCL Apps etwas kompliziert sein können (man suche das Ziel von SendMessage).

[Hansa]

Zitat:

Zitat von Dezipaitor

..Die EXE in Delphi kann man schnell kleiner machen, indem man gleich garnicht VCL verwendet.

Dann sage aber gleich dazu, dass er 100 Jahre braucht, um die Jedis usw. zu ersetzen. 8) Sofern durch so etwas überhaupt eine signifikante Reduzierung des Speicherbedarfs erreicht werden kann. Ist es möglich, dass sehr viele Grafiken im Programm enthalten sind ? Selbst bei 1.000.000 Code-Zeilen sind 12 MB ziemlich viel. Aber wie Phoenix sagt : interessieren tut es kaum.

[Bernhard Geyer]

Zitat:

Zitat von Hansa

Selbst bei 1.000.000 Code-Zeilen sind 12 MB ziemlich viel. Aber wie Phoenix sagt : interessieren tut es kaum.

1,35 Mio. Quellzeilen - 13 MB :-)

[SirThornberry]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von Hansa

Selbst bei 1.000.000 Code-Zeilen sind 12 MB ziemlich viel. Aber wie Phoenix sagt : interessieren tut es kaum.

1,35 Mio. Quellzeilen - 13 MB :-)

Mit oder ohne Formulare? für einfach nur Quelltext ohne Formulare die in Ressourcen sind finde ich das heftig.

[Bernhard Geyer]

Zitat:

Zitat von SirThornberry

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von Hansa

Selbst bei 1.000.000 Code-Zeilen sind 12 MB ziemlich viel. Aber wie Phoenix sagt : interessieren tut es kaum.

1,35 Mio. Quellzeilen - 13 MB :-)

Mit oder ohne Formulare? für einfach nur Quelltext ohne Formulare die in Ressourcen sind finde ich das heftig.

Mit VCL, 4 unterstützte DB's (Bridge-Pattern, OpenXML, Diverse Dokuformate, ....)

[Hansa]

Zitat:

Zitat von Bernhard Geyer

1,35 Mio. Quellzeilen - 13 MB :-)

Schätzung ist gar nicht so schlecht, also pro 100.000 Zeilen 1 MB. Habe in einem Fall ca. 100.000 eigene Zeilen (nur *.pas). Das ergibt ca. 1.5 MB. Glaube die SysUtils "kostet" ca. 0,5 MB und das passt dann. Also Smudo, sind es 1.2 Mio. *.pas Zeilen ? :mrgreen:

[Nils_13]

Bei meiner 0.0.0.0.0.0.0.1.001 :mrgreen: meines EgoShooters habe ich einfach einen Exe-Compressor drüber laufen lassen. Danach noch in eine tar.gz/rar/zip mit 100%-Kompression und gut ist.

[hoika]

Hallo,

- ähnliche Funktionalität in Frames auslagern,
z.B. wenn Personen ausgewählt werden sollen.

- die dcu's mal ansehen, welche die grössten sind
bei den grössten anfangen mit suchen

- eine anständige Vererbungs-Hierarchie
eine Listen-Suchfunktion muss z.B. nur einmal
implementiert werden, wenn alle Objekte von einem Basisobjekt mit
DBId als property abgeleitet sind
dann muss die Suche nach DBId nicht in jeder eigenen
Klasse noch mal programmiert werden

- gerade bei Forms
doppelte Funktionen auslagern
Formularvererbung

ich habe z.B. das "Speichere/Lade letzte Position"
in einem Hauptform, von dem die anderen abgeleitet sind

- Dlls für sich wenig verändernde Funktionen
Bsp Datenbank-Backup
man sollte aber nicht übertreiben
(Dll-Hölle)

- Plugin implementieren
ähnlich der Dlls
nicht jeder Kunde braucht (hat) alle Funktionen


Heiko

[smudo]

Zitat:

Zitat von Hansa

Also Smudo, sind es 1.2 Mio. *.pas Zeilen ? Mr. Green

Och, ich weiß nich, ich zähle nicht so genau mit :zwinker:

Vielleicht mal ein paar Werte: alleine durch die Jcl, JclVcl und JvXPCtrlsD7R wächst meine Exe schon um satte 2MB.
Die jvAppIniFileStorage macht knappe 100K aus, eine jvFormstorage nochmal 50K.
Das klingt nicht übermäßig viel, aber die Masse machts.

[Bernhard Geyer]

Zitat:

Zitat von smudo

Och, ich weiß nich, ich zähle nicht so genau mit :zwinker:

Ich auch nicht - Ich lass Delphi für mich Zählen. Musst "nur" den Compilierungsfortschritt anzeigen lassen und einek kompletten rebuild durchführen.

[smudo]

@hoika: Deine Tipps sind sehr gut. Auf alle Fälle werde ich mir die Größe der DCUs zu Gemüte führen.
Der Rest ist die Kunst der sauberen Programmierung :roll: ist nicht immer ganz einfach, wenn man unter Zeitdruck steht. Ich versuche aber auch so gut wie möglich zu vererben. Beispielsweise das Speichern/Lesen der Einstellung aus der Ini geschieht im Form0, von welchem alle weiteren abgeleitet sind.

Dlls möchte ich nicht, aber das mit den PlugIns klingt interessant. Dafür gibt es sicher schon einige Threads?

@Bernhard Geyer: Das sollte eigentlich ein Witz sein :roll:

Edit: übrigens bringt jedes leere Form (auch abgeleitete) weitere 1024 Byte.

[jbg]

Wenn du sehen willst, wieviele KB eine Unit benutzt, kannst du den JCL Project Analyzer (Menü Projekt/Analyze project) benutzen. Der zeigt nicht die DCU Größe an, sondern die Anzahl Bytes, die in die EXE reinkompiliert wurden.

[alzaimar]

Wieso will man die EXE verkleinern? Wie ich hier gelesen habe, geht es um
a) Netzlast vermeiden
b) Updates klein halten

Zu a) hätte ich eine grundsätzliche Lösung: Ich installiere auf jedem Client ein kleines Skript, das die aktuelle Version vom Netzlaufwerk auf die lokale Pladde kopiert (aber nur, wenn sie neueren Datums ist!) und dann die lokale Kopie startet. Das hat zwei Vorteile: Verkürzte Startzeit und (der eigentliche Grund) ich kann ohne Probleme jederzeit eine neue Version ins Netz stellen, ohne das Zugriffsfehler kommen. Danach kommt ein Net-Send broadcast mit der Aufforderung 'Update verfügbar! Bitte App neu starten'.

Zu b) hab ich -außer dem erwähnten Aufräumen des Codes- keine Alternative. Ich verwende DevExpress und da sind ohne eine einzige Zeile Code mal eben 6-8MB verballert. Man könnte die ganzen BPL auf dem Client installieren, aber dann hat man wieder das Upgrade-Problem... Gut, das ginge auch über ein Skript, wie unter a) beschrieben.

Meine EXEn verschicke ich leider per RAR und EMail. Da sind bei einem Upgrade auch 20MB drin. Blöd, aber nicht zu ändern.

Die größten Brocken sind neben der nicht zu vermeidenden VCL+Compos u.a. Bitmaps, Logos etc. die ich konsequent auslagere und zur Laufzeit lade.

[Bernhard Geyer]

Zitat:

Zitat von smudo

@Bernhard Geyer: Das sollte eigentlich ein Witz sein :roll:

Nicht vorm Mittagessen wenn der Zuckerspiegel niedrig ist :-)

Und ich weis ja auch nicht ob du diese Option kennst.

[smudo]

@jbg: Genau sowas hab ich gesucht. Vielen Dank.

@alzaimar: eine ähnliche Updateroutine verwenden wir hier auch.

@Bernhard Geier: War auch nicht böse gemeint :)