Hallo allerseits !

Vielleicht bin ich ein wenig kritisch, aber mir ist das Folgende aufgefallen: Beim selben Programmcode werden die erstellten EXE-Dateien unter Delphi XE2 deutlich grösser als unter Delphi 6. Die Veränderung beträgt ca. einen Faktor 2 bis 4. Ein Problem ist dies nicht, da in der Zwischenzeit auch die Festplatten viel grösser (bzgl der Kapazität) geworden sind. Ich frage mich jedoch, was die Gründe dafür sind ?


Gruss,


Hochhaus


Moderiert von Narses: Topic aus Sonstiges (Delphi) verschoben am Mi 13.06.2012 um 16:05

Schalt mal das RTTI (was es bei Delphi 6 noch nicht gab) aus.
docwiki.embarcadero....I-Direktive_(Delphi)

Nersgatt hat folgendes geschrieben :

Schalt mal das RTTI (was es bei Delphi 6 noch nicht gab) aus. docwiki.embarcadero....I-Direktive_(Delphi)

Ok. Und wie tue ich das ? Aus der Dokumentation werde ich nicht schlau, wie ich das anstellen soll. {$RTTI ????}

Hochhaus

Sie sind größer, da andere (überarbeitete) Units enthalten sind, die dadruch größer sind. DU gibst vielleicht den selben Code ein, aber es wird weiterhin andere noch mit eingebunden... Bei delphi XE sind sie erweitert worden und somit meist größer...

Hochhaus hat folgendes geschrieben :

Nersgatt hat folgendes geschrieben : Schalt mal das RTTI (was es bei Delphi 6 noch nicht gab) aus. docwiki.embarcadero....I-Direktive_(Delphi) Ok. Und wie tue ich das ? Aus der Dokumentation werde ich nicht schlau, wie ich das anstellen soll. {$RTTI ????}

www.zipplet.co.uk/in...mming_delphi2010rtti

Danke ! Ok ! Es funktioniert. Die Grösse der EXE-Datei wird aber nicht viel reduziert (von ca. 1430 kB auf 1300 kB).

Hochhaus

Hochhaus hat folgendes geschrieben :

Danke ! Ok ! Es funktioniert. Die Grösse der EXE-Datei wird aber nicht viel reduziert (von ca. 1430 kB auf 1300 kB).

Ich vermute, daß Du das Entfernen der Laufzeittypinformationen nur auf Dein Projekt selbst anwandtest, aber nicht auf die mitgelieferten Delphi-Units. Nachdem ich auch die Standardunits dem Procedere / "Rumgemache" erfolgreich unterwerfen konnte (ich glaube, daß es bis auf die Unit "system" so ziemlich alle waren), ließ sich bei mir die Größe der Compilate um ca. 30% verringern.

Keine Ahnung, warum die mitgelieferten Vorcompilate nicht gleich optimale Qualität aufweisen können. Naja, vielleicht benötigt man die RTTI in irgendwelchen speziellen Fällen doch (auch darob habe ich keine Ahnung), dann wäre das Belassen derselben natürlich berechtigt bis nötig.

Delphi-Laie hat folgendes geschrieben :

Naja, vielleicht benötigt man die RTTI in irgendwelchen speziellen Fällen doch (auch darob habe ich keine Ahnung), dann wäre das Belassen derselben natürlich berechtigt bis nötig.

In relativ vielen. Aber solange du nicht viele der neuen Features benutzt, wirst da auch kein Problem bekommen. Viele davon verlassen sich jedenfalls sehr stark auf die RTTI-Informationen. Sei es für Multi-Tier Geschichten mit DataSnap oder etwas anderes. Und auch ich benutze es immer wieder.

Ohne diese Informationen wäre also im Gegenteil gar nix optimal. Außer für Speicherschotten, die weniger Speicherplatz zu verbrauchen wichtiger als Features finden.

Hallo Sebastian, was Du dort an Dingen aufzählst ("MultiTier", "DataSnap"), ist mir leider unbekannt. Bitte gestatte mir deshalb dazu mal ein paar ganz dumme Anfängerfragen:

Wie bekommt man mit, daß man (mit) etwas programmiert, was die Laufzeittypsinformation benötigt, man diesem aber diese (in der o.a. Weise) vorenthält? Wird dann schon das Compilieren verweigert oder nur mit Warnungen garniert? Oder merkt man es erst an der fertigen Exe? Falls ja, wie: Gibt es aussagekräftige Fehlermeldungen, oder "spinnt" das Programm dann in nicht vorhersehbarer Weise?

Danke für Deine Geduld und Mühe mit mir!

Gruß Delphi-Laie

Delphi-Laie hat folgendes geschrieben :

Wird dann schon das Compilieren verweigert oder nur mit Warnungen garniert? Oder merkt man es erst an der fertigen Exe? Falls ja, wie: Gibt es aussagekräftige Fehlermeldungen, oder "spinnt" das Programm dann in nicht vorhersehbarer Weise?

Es kann sich nur so äußern, dass es sich nur falsch verhält, da der Compiler keine Möglichkeit hat das mitzubekommen. Es geht ja gerade um Informationen, die zur Laufzeit abgerufen werden.

Ob es dann einen Fehler gibt, hängt davon ab, was an der Stelle passiert. Es kann auch sein, dass schlicht davon ausgegangen wird, dass keine Daten da sind, und es nicht direkt erkannt wird. Das müsste man im Einzelfall ausprobieren, das kann man aufgrund der Vielzahl an Anwendungsmöglichkeiten nicht allgemein sagen.

Das Beispiel zu Attributen stürzt z.B. schlicht mit einer Zugriffsverletzung ab, wenn man in der Test-Unit die RTTI-Informationen deaktiviert:
Ganz einfach, weil sich der Code darauf verlässt, dass die RTTI-Informationen für die Klasse da sind und daher TRttiObject.GetAttributes aufgerufen werden kann.

Vielleicht ist ja UPX etwas für Dich
upx.sourceforge.net/

bummi hat folgendes geschrieben :

Vielleicht ist ja UPX etwas für Dich upx.sourceforge.net/

Danke, Bummi, das kenne ich seit langem, und dazu habe ich ein gespaltetes Verhältns: Kleinere Exe auf der Platte, jedoch größere im Speicher.

Für die generelle Compilatsverkleinerung (als Ergebnis des Compilierens, nicht danach) gibt es ja unendlich viele Diskussionen, hier meine bisherige Sammlung:

1. NonVCL
2. Nicht benötigte Units entfernen
3. benötigte Units abspecken, ggf. nur benötigten Code extrahieren und entsprechende Unit(s)
entfernen
4. Debuginformationen in Compiler/Linker entfernen:
ALT+F11 -> Compiler
Haken bei
- Optimierung an
- bei [Laufzeitfehler] und [Debuggen] alles weg
5. RTTI:
{$weaklinkrtti on}
{$rtti explicit methods([]) properties([]) fields([])}
6. KOL-(System-)Units verwenden
7. Möglichst kleine / frühe Delphiversion verwenden
(8. upx)

Oder eben "Fremdgehen": Das Visual-Studio ermöglicht viel kleinere Compilate (vor allem bei C++, während C# mit den Zwischencode aus der Vergleichbarkeit ein wenig herausfällt). Zu C & Co. konnte ich bis heute aber keine Zuneigung, erst recht keine Liebe empfinden.

Delphi-Laie hat folgendes geschrieben :

Oder eben "fremdgehen": Das Visual-Studio ermöglicht viel kleinere Compilate (vor allem bei C++, währen C# mit den Zwischencode aus der Vergleichbarkeit ein wenig herausfällt).

Du kannst bei Delphi doch auch Runtime Packages benutzen. Das ist dann in etwa wie bei C++ mit der Visual C++ Runtime und die Größe der Exe-Dateien ist dann auch vergleichbar.

Ob das Sinn macht, ist eine andere Frage, aber möglich ist es.

// EDIT:
Zum Vergleich:
Unsere Hauptanwendung ist über 30 MiB groß...

Moderiert von Narses: Komplett-Zitat des letzten Beitrags entfernt.

Das weiß ich, doch dann ist die Exe nicht mehr universell auf jedem (32-Bit-)Windows lauffähig -> Weitergabe problematisch. Das sind dann eben auch keine "echten" Compilate.

In Windows muß eine andere Bibliothek als die VCL integriert sein (letztere stammt ja ursprünglich von Borland), und ich weiß bis heute nicht genau, welche. Bei Nir Sofer (nirsoft.net) finden sich Exe-Dateien mit großem Funktionsumfang, die teilweise nur ein paar kByte groß sind und teilweise sogar noch auf Windows 9.x (bei mir: ME) laufen. Ich konnte ihm nur das Geheimnis entlocken, daß sie mit dem Microsoft Visual Studio erstellt wurden (C++ nennt er ja von sich aus als Programmiersprache).

Delphi-Laie hat folgendes geschrieben :

In Windows muß eine andere Bibliothek als die VCL integriert sein (letztere stammt ja ursprünglich von Borland), und ich weiß bis heute nicht genau, welche. Bei Nir Sofer (nirsoft.net) finden sich Exe-Dateien mit großem Funktionsumfang, die teilweise nur ein paar kByte groß sind und teilweise sogar noch auf Windows 9.x (bei mir: ME) laufen. Ich konnte ihm nur das Geheimnis entlocken, daß sie mit dem Microsoft Visual Studio erstellt wurden (C++ nennt er ja von sich aus als Programmiersprache).

Du musst ja nicht die Bibliotheken nutzen, die in Visual C++ zur Verfügung stehen. Wenn du das nicht tust, brauchst du (zumindest bei alten Visual C++ Versionen) auch keine Runtime. Komfortabel ist das aber logischerweise nicht.

jaenicke hat folgendes geschrieben :

Du musst ja nicht die Bibliotheken nutzen, die in Visual C++ zur Verfügung stehen. Wenn du das nicht tust, brauchst du (zumindest bei alten Visual C++ Versionen) auch keine Runtime. Komfortabel ist das aber logischerweise nicht.

Ohje, ich verstehe Dich kaum.

Irgendwo müssen die Bibliothken (Runtime) ja stecken. Bei kleinen Exe-Dateien, so suggeriert es mir deren geringe Größe, sind sie ausgelagert, also nicht darin enthalten, und werden dann eben zur Laufzeit nachgeladen - wo immer sie sich auf der Platte auch herumtreiben, aber - über die Pfadvariable? - (hoffentlich) gefunden werden.

Von Delphi und C++ (Borland) kenne ich das durchaus, auch von den elenden VB-Dateien (früher), von denen immer die gerade benötigte natürlich fehlte. (Das gleiche Phänomen wiederholt sich - auf höherem Niveau - übrigens mit dem Dot-Net-Geraffel, bei dem auch immer wieder die gerade benötigte Version gerade nicht installiert ist - einer der Gründe, warum ich das so "liebe").

Nur, die NirSoft-Programme laufen teilweise ja sogar noch auf 9x-Windows. Dort hatte und habe ich kein Visual-Studio installiert. Also muß Windows diese Bibliotheken integiert haben, richtig?

Inwiefern das nicht komfortabel sein soll, erschließt sich mir nicht, aber das meinst Du vielleicht auch nicht. Unkomfortabel ist es hingegen, die Bibliotheken beizulegen (überhaupt erst einmal daran denken zu müssen) bzw. beim Empfänger, wo natürlich die Bibliotheken fehlen und der Absender diese beizulegen vergaß, dann zu besorgen, evlt. beim Absender danach zu betteln. Deshalb liebe ich Delphi mit seinen komfortablen Voreinstellungen so (nur eben nicht dessen Compilatsgrößen). Beim C++-Builder muß man das extra einstellen, und dessen Compilate sind dann noch größer.

Nein, du brauchst nicht unbedingt eine Runtime bei C++. Aber das ist wie bei Non-VCL in Delphi, es geht, aber es fehlt halt jeglicher Komfort, so dass man damit schlecht produktiv arbeiten kann.
Denn da muss man eben alles selbst machen und schreibt dann entsprechend viel Code für banale Standardgeschichten, die es eigentlich schon fertig gibt. Dafür steckt in der erzeugten Exe eben auch nur der Code, der wirklich gebraucht wird, so dass diese auch ohne Bibliothek klein ist.

Und wenn man einen anderen C++ Compiler als Visual C++ benutzt, braucht man die MS Runtimes ohnehin nicht.

Nun ist es völlig klar, danke!

Ist also sozusagen das Pendant zur Unit-Abspeckung oder gar der VCL-freien Programmierung in Delphi. Beides ist sehr mühsam, zeitaufwendig und fehlerträchtig.

Geht es also doch nicht ohne massives zusätzliches Rumgemache, C++-Compilate so klein hinzubekommen (was ich hoffte und vermutete). Aber Nir Sofer als "Hardcoreprogrammierer" scheut solche Mühen eben nicht.

Oder mit eben C# (und anderen .net-Programmierumgebungen wie Delphi Prism?, aber das/die liefert/liefern ja keinen nativen Code.

Aber daß ich zu C & Consorten wechseln werde, ist sehr unwahrscheinlich. Deren Quelltexte sind einfach nach wie vor eine zu große Mühsal für mich.

Delphi-Laie hat folgendes geschrieben :

Ganz so günstig ist es leider doch nicht, denn das "Abspecken" der Units ("Ausmisten" nicht benötigter i.S.v. (nicht) aufgerufener Programmteile) verringert die Exe-Dateigröße spürbar.

weil fast jede Unit inzwischen auch einen initialize-code-Teile hat, der immer durchlaufen wird, wenn die Unit eingebunden ist. Das ist, meiner Meinung nach, nicht gut gelöst.

Gruß,
WiWo

Erstens dauern diese Initialisierungsabschnitte in der Regel nur einige Mikrosekunden und zweitens:
Wie würdest du die unitinternen Sachen denn sonst initialisieren ohne in die Gefahr zu laufen, dass ein Aufruf passiert bevor die Initialisierung abgeschlossen ist?