DLL mit FPC/Codetyphon erheblich kleiner als unter Delphi

[Der schöne Günther]

Meinst du das jetzt wirklich ernst? Lieber kleinere Exen machen (und Compiler-Strom sparen) statt nicht auf dem Stand von Delphi 7 stehen zu bleiben?

[TRomano]

Mittlerweile wird das ja mal wieder eine Grundsatzdiskussion :(

Jeder muss da seinen Frieden finden. EMBA wird wie gesagt keine mannjahre in einen optimierenden Compiler stecken, um ein paar Kunden welweit mehr zu aquirieren.
Wer selber optimieren will/muss, der sollte es auch selber tun. Die Einarbeitungskurve ist allerdings hoch. Ich habe gerne den HLA von Randall Hyde genommen, aber erst einmal seine Bücher gelesen, mich eingearbeitet und dann wurde ich langsam produktiv ... das bezahlt heute doch kein Auftraggeber mehr, wenn er es nicht unbedingt braucht.
Als Hobby kann man gerne machen, lernt dabei auch was über den Aufbau der CPU und ihren Befehlssätzen und kann das Wissen in purem Pascal-Code auch nutzen. Wenn man das stringent durchziehen will und dann noch ein Projekt hat, was Intel, Android usw. unterstützen soll, dann viel Spaß beim Proggen. Sicherlich gibt es weltweit Projekte in denen Assembler eingesetzt wird, aber das läuft wie in C++ über Instrincts, wo der Compiler dann entsprechenden Code erzeugt.

Die Freude, unter Verwendung von BASM, dem Delphi-Compiler Schnippchen zu schlagen ist trotzdem groß :)

[BUG]

Zitat:

Zitat von TRomano (Beitrag 1337634)

Mittlerweile wird das ja mal wieder eine Grundsatzdiskussion :(

Jup, allgemeinen Kulturpessimismus hab ich genug, das brauch ich nicht auch noch beim Diskutieren von Compilern :mrgreen:

Ich vermute auch, dass sich die Anzahl der Leute, die Numerik mit Delphi betrieben, in Grenzen hält. Für C++ gibt so viele schöne (relativ) gut gewartete Bibliotheken und optimierende Compiler (+ Erweiterungen). Allerdings stellt sich dann die Frage, warum ich für den Rest nicht gleich eine gemanagedte Laufzeitumgebung ... aber gut, dass wurde ja auch schon zu Genüge diskutiert :wink:

[EWeiss]

Zitat:

Mittlerweile wird das ja mal wieder eine Grundsatzdiskussion

Jup.. Deshalb ziehe ich mich auch aus den Thema zurück.
Was Hänschen nicht lernt, lernt Hans nimmermehr.

gruss

[Delphi-Laie]

Zitat:

Zitat von EWeiss (Beitrag 1337517)

Zitat:

So schlimm ist es nach meiner Wahrnehmung zum Glück nun auch wieder nicht.

Nein?

Nein. Ich experimentierte mal mit den uses-Units. Überflüssige hinzugefügt oder entfernt, machte nicht den Größenunterschied der Exe-Compilate aus, wie die DCUs groß sind, sondern dieser Größenunterschied war geringer.

Zitat:

Zitat von Neutral General (Beitrag 1337518)

Ich finde eure Argumentation total unsinnig.

Die einstelligen MB-Unterschiede machen heutzutage überhaupt nichts aus. Das hat quasi keinen messbaren negativen Einfluss auf irgendwas.

Und was ist mit den Quota-Limits in diversen Delphi-Foren?

[Delphi-Laie]

Zitat:

Zitat von EWeiss (Beitrag 1337522)

Zitat:

Zitat von hoika (Beitrag 1337520)

Hallo,
bringen die RTTI-Compilerschalter nicht ein bisschen?


Heiko

Nein bringen nichts :oops: War einer meiner ersten versuche.

Da gab es doch mal eine Anleitung "Remove RTTI" aus (Delphi-2010)-Compilaten. Das hatte bei mir unter XE2 einen deutlichen Einfluß, verringerte die Compilatsgrößen spürbar. Ich tat es gemäß dieser Anleitung.

[Delphi-Laie]

Zitat:

Zitat von TiGü (Beitrag 1337624)

Zitat:

Zitat von EWeiss (Beitrag 1337623)

Zitat:

Offen gestanden hatte ich in all den vergangenen Jahren nicht ein einziges Kundenprojekt, bei dem ein MB mehr oder weniger bei den EXEn irgendwie relevant geworden wäre.

Ach darum geht's doch gar nicht..
Es geht um die Verschwendung von Ressourcen.
Das fängt damit an das man meint jedes Lebensmittel wo das Ablaufdatum ausgelaufen ist wegwirft und hört hier bei Bit und Bytes auf.
Mal überlegt wie viel Strom man sparen könnte wäre unsere Gesellschaft KEINE Wegwerfgesellschaft?

Man spart aber keinen Strom, wenn die EXE ein, zwei Megabyte kleiner ist! :roll:

Dann werden diese "ein, zwei Megabyte" also ohne Energieaufwand gespeichert bzw. übertragen?

[EWeiss]

Zitat:

Da gab es doch mal eine Anleitung "Remove RTTI" aus (Delphi-2010)-Compilaten. Das hatte bei mir unter XE2 einen deutlichen Einfluß, verringerte die Compilatsgrößen spürbar. Ich tat es gemäß dieser Anleitung.

Dank!
Werde mal testen ob das was bringt.

EDIT:
Hab das mal getestet :)
Bringt bei mir gerade mal 40KB ohne Verwendung von UPX


gruss

[TiGü]

Zitat:

Zitat von Delphi-Laie (Beitrag 1337651)

Zitat:

Zitat von TiGü (Beitrag 1337624)

Zitat:

Zitat von EWeiss (Beitrag 1337623)

Zitat:

Offen gestanden hatte ich in all den vergangenen Jahren nicht ein einziges Kundenprojekt, bei dem ein MB mehr oder weniger bei den EXEn irgendwie relevant geworden wäre.

Ach darum geht's doch gar nicht..
Es geht um die Verschwendung von Ressourcen.
Das fängt damit an das man meint jedes Lebensmittel wo das Ablaufdatum ausgelaufen ist wegwirft und hört hier bei Bit und Bytes auf.
Mal überlegt wie viel Strom man sparen könnte wäre unsere Gesellschaft KEINE Wegwerfgesellschaft?

Man spart aber keinen Strom, wenn die EXE ein, zwei Megabyte kleiner ist! :roll:

Dann werden diese "ein, zwei Megabyte" also ohne Energieaufwand gespeichert bzw. übertragen?

Bitte rechne uns doch mal ausführlich vor, wie viel Energie oder Leistung beim Speichern einer ein Megabyte großen Datei aus dem Arbeitsspeicher auf deine Festplatte verbraucht wird.
Wahlweise kannst du natürlich auch den umgekehrten Fall präsentieren, also das Öffnen. :thumb:

[EWeiss]

Zitat:

Bitte rechne uns doch mal ausführlich vor, wie viel Energie oder Leistung beim Speichern einer ein Megabyte großen Datei aus dem Arbeitsspeicher auf deine Festplatte verbraucht wird.

Wollte eigentlich nichts mehr dazu sagen aber gut.

Hallo?
Es geht hier nicht um 1 MB, es geht hier um die Summe ALLER von Delphi Developer erstellten\kompilierten Projekte.
Das 1 MB hier kaum oder so gut wie gar nicht zu buche schlagen sollte wohl klar sein.

Wie viel petaByte an Speicher wirst du dann wohl verwenden und was kostet das diese auf Speichermedien zu kopieren?
Da muss man nicht rechnen schau doch einfach mal was der Betrieb eines Servers im Monat kostet dann hast du deine Antwort.
1 PetaByte kostete etwas 500.000 Dollar und das ist noch ein Schnäppchenpreis. (Die andere Hardware die ebenfalls Strom verbraucht nicht mit eingerechnet)

http://www.tomshardware.de/fotorepor...abyte-sas.html
Nun eine Rechenaufgaben an dich..
Wie viel Terabyte könnte man wohl einsparen wenn die Summe aller erstellten\kompilierten Projekte um nur 1 MB reduziert würden?


gruss

[TiGü]

Ich sehe den Zusammenhang zwischen den von dir und mir erstellten Delphi-Binaries und den Kosten einer Serverfarm nicht?!? :gruebel:

Gebe mir doch bitte eine grobe Schätzung, wie groß der Anteil (absolut oder relativ) der Delphi-Binaries aller Delphi-Entwickler auf der ganzen weiten Welt am weltweiten Internetdatenverkehr ist.
Kopierst du deine einstellig Megabyte großen DLLs und EXEn quer durch ganze Netz auf einen Server in Australien? Und das tausende Male am Tag 24/7? :shock:

[Der schöne Günther]

Bitte nicht weiter zanken, das macht mich seelisch ganz fertig.

Für manche Leute ist das anscheinend sehr wichtig, und dagegen kann man wohl auch nichts (mehr) machen. Die Tatsache dass "FPC" anscheinend kleinere Dateien macht haben wir nach sechs Seiten wohl auch schon geklärt.

Lasst alle ein Eis nehmen und in die Sonne setzen.

[EWeiss]

Zitat:

Lasst alle ein Eis nehmen und in die Sonne setzen.

Gute Idee :)

gruss

[Neutral General]

Zitat:

Zitat von EWeiss (Beitrag 1337666)

Zitat:

Lasst alle ein Eis nehmen und in die Sonne setzen.

Gute Idee :)

gruss

Wer als letztes noch vorm PC sitzt hat Recht :stupid:

[Delphi-Laie]

Zitat:

Zitat von EWeiss (Beitrag 1337654)

Zitat:

Da gab es doch mal eine Anleitung "Remove RTTI" aus (Delphi-2010)-Compilaten. Das hatte bei mir unter XE2 einen deutlichen Einfluß, verringerte die Compilatsgrößen spürbar. Ich tat es gemäß dieser Anleitung.

EDIT:
Hab das mal getestet :)
Bringt bei mir gerade mal 40KB ohne Verwendung von UPX

"Leeres" Formularprogramm? Nur 32 Bit?

Die Ersparnis ist (jedenfalls absolut) umso größer, je mehr Bit(s) das Programm hat, je mehr Units eingebunden werden und je mehr davon mit "RTTI disabled" (vor-)compiliert wurden (bei der Unit "system" z.B. dürfte das mit den verfügbaren "Hausmitteln" unmöglich sein). Ich war mit der Einsparung jedenfalls zufrieden. Allerdings entfernte ich auch gleich noch das abartig große Icon mit seinen ca. 300 kByte).

[hoika]

Hallo,
also den Link mit dem reziproken div fand ich hier am spannendsten.
Den habe ich mir Trotz Urlaub genau angesehen.


Heiko

[jaenicke]

Wenn wir hier schon am hochrechnen sind:
Upx nun ja auch schon genannt. Wenn ich den Speicherplatzverbrauch gegen das jeweilige Entpacken bei jedem Start hochrechne...

Zitat:

Zitat von Delphi-Laie (Beitrag 1337674)

Allerdings entfernte ich auch gleich noch das abartig große Icon mit seinen ca. 300 kByte).

Das können wir nicht machen, denn wenn man die größte Icongröße im Windows-Explorer eingestellt hat, sieht es dann schlecht aus. Deshalb haben wir auch ein 256er PNG mit Transparenz eingebunden.

Gleiches gilt für die RTTI. Die können wir ebenfalls nicht entfernen, weil wir sie schlicht verwenden.

Für das was wir alles verwenden, finde ich z.B. 20MiB für unsere Release Version aber auch nicht zu viel.

Ich wundere mich, dass ihr noch niemand Runtime-Packages erwähnt hat. Mit denen lässt sich am allermeisten Speicherplatz sparen, sobald man mehrere DLLs mitliefert. Da werden die Anwendungen und DLLs erst richtig klein.

[Delphi-Laie]

Zitat:

Zitat von jaenicke (Beitrag 1337687)

Ich wundere mich, dass ihr noch niemand Runtime-Packages erwähnt hat. Mit denen lässt sich am allermeisten Speicherplatz sparen, sobald man mehrere DLLs mitliefert.

Hm...wird normalerweise nicht von Delphi ein Compilat erstellt (exe oder dll)?

Natürlich kann man mit dem Auslagern in DLLs "rummachen", sich jedoch damit auch sehr viel zusätzliche Arbeit verpassen.

Oder Du meinst etwas ganz anderes. Ich werde mal nach diesen (ominösen) "Runtime-Packages" recherchieren.

[Luckie]

Die Runtime Packages werden standardmäßig einkompiliert. Man kann sie aber auch nicht mit eincompilieren, dann muss man die zugehörigen BPLs mit ausliefern.

[Erdbär]

Seit Delphi 2006 Professional hat sich also nichts geändert?

[jaenicke]

An den Runtime Packages? Nein.

Dafür aber eben sehr viel anderes.

[Delphi-Laie]

Zitat:

Zitat von Luckie (Beitrag 1337710)

Die Runtime Packages werden standardmäßig einkompiliert. Man kann sie aber auch nicht mit eincompilieren, dann muss man die zugehörigen BPLs mit ausliefern.

Dann weiß ich, was gemeint ist, danke! Im C++-Builder (jedenfalls in den unteren / kleinen Versionen) ist es umgekehrt voreingestellt, dort muß man das explizit einstellen, daß das Compilat alles inklusiv hat, was es außer Windows noch alles benötigt.

Die Runtime-Packages nicht zu inkludieren, ist aber den Teufel mit dem Beelzebub ausgetrieben. Ein solches Kompilat ist jenseits eines Windows, bei dem nicht die speziell benötigte Delphi-Version installiert ist, praktisch nicht zu gebrauchen. Ich kenne jemanden persönlich, der (versehentlich?) jemandem eine Arbeitsprobe - Testprogramm o.ä. - zusandte, die / das mehr als nur die Windows-Umgebung benötigte. Vermutlich ging es auch um fehlende Runtime-Packages. Kurzum, der erste Eindruck entschied ("Mist, läuft nicht"), mit der Folge, daß wegen der Verärgerung kein Auftrag zustandekam.

Also, das ist keine Alternative, sondern hat sogar die starke Tendenz zur Selbstsabotage.

[DeddyH]

Zitat:

Zitat von Delphi-Laie (Beitrag 1337731)

Die Runtime-Packages nicht zu inkludieren, ist aber den Teufel mit dem Beelzebub ausgetrieben. Ein solches Kompilat ist jenseits eines Windows, bei dem nicht die speziell benötigte Delphi-Version installiert ist, praktisch nicht zu gebrauchen.

Wieso sollte Delphi auf dem Zielrechner installiert sein? Wenn man mit Runtime-Packages kompiliert, muss man diese dann eben mitliefern. Das Dumme dabei ist, dass sie auch zur verwendeten Compiler-Version passen müssen, d.h. ein z.B. mit Delphi 7 kompiliertes Package kann auch nur in einem ebenfalls unter Delphi 7 kompilierten Programm verwendet werden.

[Delphi-Laie]

Zitat:

Zitat von DeddyH (Beitrag 1337734)

Zitat:

Zitat von Delphi-Laie (Beitrag 1337731)

Die Runtime-Packages nicht zu inkludieren, ist aber den Teufel mit dem Beelzebub ausgetrieben. Ein solches Kompilat ist jenseits eines Windows, bei dem nicht die speziell benötigte Delphi-Version installiert ist, praktisch nicht zu gebrauchen.

Wieso sollte Delphi auf dem Zielrechner installiert sein?

Eben - viele (die meisten?), die mit Delphi erstellte Programme benutzen, sind noch lang nicht deren Programmierer.

Zitat:

Zitat von DeddyH (Beitrag 1337734)

Wenn man mit Runtime-Packages kompiliert, muss man diese dann eben mitliefern.

Nochmals eben (außer, daß Du wahrscheinlich "ohne" meintest). Nur, erstens muß man daran denken und zweitens muß die Menge der benötigten Runtime-Packes-Dateien vollständig sein. Dazu muß man einen Delphi-freien Computer haben, um das abzusichern.

Zitat:

Zitat von DeddyH (Beitrag 1337734)

Das Dumme dabei ist, dass sie auch zur verwendeten Compiler-Version passen müssen, d.h. ein z.B. mit Delphi 7 kompiliertes Package kann auch nur in einem ebenfalls unter Delphi 7 kompilierten Programm verwendet werden.

Zum dritten Male: Eben! Was schrieb ich vom Teufel und dem Beelzebub?

Außerdem wird so - bei einmaliger Compilatweitergabe - gar nichts an Speicherplatz gespart, ganz im Gegensatz, das Rumgemache mit den vielen Einzeldateien dürfte die weiterzugebende Datenmenge tendenziell eher noch aufblähen. Erst ab dem zweiten Compilat hat man ggf. etwas gespart, je mehr Compilate, umso mehr. Da lobe ich mir doch ein "natives", ohne weitere Einschränkungen (jedenfalls keine von Delphi verusachten) lauffähiges Compilat.

[hanvas]

Zitat:

Zitat von Delphi-Laie (Beitrag 1337731)

Die Runtime-Packages nicht zu inkludieren, ist aber den Teufel mit dem Beelzebub ausgetrieben. Ein solches Kompilat ist jenseits eines Windows, bei dem nicht die speziell benötigte Delphi-Version installiert ist, praktisch nicht zu gebrauchen.

Die Möglichkeit nicht alles in ein Binary (ob DLL oder Exe) hineinzupacken und stattdessen binäre Runtime-Packages zu verwenden ist einer der letzten Gründe warum ich Delphi gegenüber FPC bevorzuge - und das hat nichts mit dem Platz zu tun, sondern eher das man auf diese Art komplexe Applikationen strukturieren kann und durch Austausch, Weglassen oder hinzufügen von Packages auf binärer Ebene (also wie eine Art Plugin) das Verhalten und die Funktionalität der Applikation verändern kann.

cu Ha-Jö

[Luckie]

Zitat:

Zitat von Delphi-Laie (Beitrag 1337731)

Die Runtime-Packages nicht zu inkludieren, ist aber den Teufel mit dem Beelzebub ausgetrieben. Ein solches Kompilat ist jenseits eines Windows, bei dem nicht die speziell benötigte Delphi-Version installiert ist, praktisch nicht zu gebrauchen.

Wenn ich die Runtime Packages nicht mit eincompiliere, dann sollte ich auch wissen, dass ich die Zugehörigen BPLs mitliefern muss.

Zitat:

Ich kenne jemanden persönlich, der (versehentlich?) jemandem eine Arbeitsprobe - Testprogramm o.ä. - zusandte, die / das mehr als nur die Windows-Umgebung benötigte. Vermutlich ging es auch um fehlende Runtime-Packages. Kurzum, der erste Eindruck entschied ("Mist, läuft nicht"), mit der Folge, daß wegen der Verärgerung kein Auftrag zustandekam.

War wohl auch besser so. Da derjenige wohl nicht wusste, was er tut.

Zitat:

Also, das ist keine Alternative, sondern hat sogar die starke Tendenz zur Selbstsabotage.

Nicht wenn man weiß, was man tut.

Die Tuneup Utilities machen es zum Beispiel so, dass sie alle benötigten BPLs mitliefern. Und ich kann nicht sagen, dass sie sich selbst sabotiert haben.

[TRomano]

Es wird genau dann schwierig, wenn viele Delphi-Programme auf einem Rechner mit Runtime packages laufen. In einem längeren Projekt im Süddeutschen hatten wir das Problem,
da dort die verschiedensten Delphi-Programme auch mit den unterschiedlichsten Kompilaten liefen, von D7, über D2010, XE, XE5, und XE7. Hier mit Runtime packages zu arbeiten hätte einen erhöhten Administrationsaufwand erfordert. Dann lieber eine größere Exe-Datei und die Admins sind glücklich ...
Wenn ich allerdings, wie dort, viele Delphi-Programme am laufen habe und alle mit dem selben Delphi-Compiler erstellt werden kann man darüber nachdenken.
Ach nee .. wenn man seine Komponenten-Sammlungen updated und den eigenen Sourcecode gleichzeitig ändert oder nutzt neue Features der Komponenten-Sammlungen ... dann hat man ein Problem oder verschiedene Versionen der BPL´s, die dann wieder irgendwo lokal herumlungern müssen. Man kann sich das Leben auch schwer machen :wink:

[hoika]

Hallo,
also die BPLs der verschiedenen Versionen sollten schon versionsbezogene Namen haben ...
Und zum Test muss man eh verschiedenn "leere" Rechner (virtuelle Maschinen) haben.

Aber auch wir benutzen keine Packages, aus schon gesagten diversen Gründen.

[TRomano]

Ja, das haben sie auch ...
Ob allerdings eine "cxDataRS24.bpl" (DevExpress) aus der Version 15.2.4 kompatibel mit der 15.2.5 ist (bei gleichem Namen), ist eben nicht sichergestellt. Da kommen schon mal gerne die Fehlermeldung, dass eine Func/Proc nicht an einer bestimmten Adresse gefunden werden kann.

[jaenicke]

Deshalb kann man ja auch einstellen welche Packages als Runtime Packages eingebunden werden sollen. So kann man das auf die von Delphi selbst beschränken.