DLL mit FPC/Codetyphon erheblich kleiner als unter Delphi

[Benedikt Magnus]

Dazu fällt mir dieser Artikel hier ein:
http://blog.synopse.info/post/2015/0...er-than-Delphi

[ralfstocker]

Danke!

Zitat von Benedikt Magnus:

Dazu fällt mir dieser Artikel hier ein:
http://blog.synopse.info/post/2015/0...er-than-Delphi

[jaenicke]

Auch der neuere 64-Bit Compiler von Delphi benutzt diese Optimierung übrigens nicht.
Es stimmt auch, dass dadurch diese Zeile in FPC Code etwa viermal schneller ausgeführt wird.
Allerdings lässt sich selbst ohne Optimierung diese Zeile auf meinem nicht ganz neuen Rechner 100 Millionen mal in einer Sekunde ausführen, bei FPC eben viermal so oft.

In wie vielen realen Programmen wird dies also relevant sein?

An der Stelle finde ich, dass es nicht unbedingt sinnvoll ist, zu viel Aufwand in "extreme corner case" Optimierungen zu stecken... zumindest nicht in einem kommerziellen Produkt wie Delphi.

[BUG]

Kommt immer darauf an. Ereignisgetriebene Datenbankoberflächen (CRUD-Anwendungen) ist das vermutlich egal, da eh alle paar Instruktionen irgendwo hin gesprungen wird.
Hier im Forum habe ich aber auch einige Leute gesehen, die numerische Simulationen in Delphi schreiben. Und in einer engen Schleife bedeutet 4x länger halt, dass die Simulation 4x länger läuft.

[TRomano]

Die Relevanz (millionenfaches Berechnen in einer engen Schleife) ist wohl bei den allermeisten Entwicklern gering.
In meinem bisherigen Entwicklerleben hatte ich einmal das Vergnügen (Landesamt für Statistik) und dort wurde dann gleich zu SSE2/SSE3 gegriffen, also wurde der interne BASM angeschmissen
und nur Arrays, Listen etc. an die Func/Proc übergeben und der Rest intern mit dem Assembler gemacht. Oder man hat gleich extern (High Lever Assembler HLA) programmiert und die OBJ-Files in Delphi eingebunden.

Natürlich wünschen wir uns alle hochoptimierten Code, aber auf der anderen Seite wollen wir einen flinken Compiler/Linker, dass wir effizient arbeiten können. Das ist Delphi (fragt mal einen C oder C++ - Entwickler). Vor 20-25 Jahren musste man echt noch auf die Größe der Kompilate achten, aber heute ist das nicht mehr relevant.

Schön wäre es natürlich, wenn man normal mit Delphi entwickeln könnte und bei der Fertigstellung eines Releases einfach den Compiler mit einer hohen Optimierungsstufe anschmeissen könnte. Der Linker würde danach automatisch alle Funcs/Procs/Consts/... aus eingebundenen Units rausschmeißen, die man nicht braucht ...

[EWeiss]

Zitat:

musste man echt noch auf die Größe der Kompilate achten, aber heute ist das nicht mehr relevant.

Destotrotz sehe ich keinerlei Nutzen darin warum Kompilate so dermaßen aufgebauscht werden müssen.

Zitat:

Schön wäre es natürlich, wenn man normal mit Delphi entwickeln könnte und bei der Fertigstellung eines Releases einfach den Compiler mit einer hohen Optimierungsstufe anschmeissen könnte. Der Linker würde danach automatisch alle Funcs/Procs/Consts/... aus eingebundenen Units rausschmeißen, die man nicht braucht ...

Wobei man das letztendlich mit UPX bewerkstelligen kann/könnte.
Schöner wäre es natürlich direkt in der IDE mit einstellbaren Optimierungs flags.
Aber was rede ich hier den aufwand zu betreiben ist den Entwicklern von Delphi einfach nicht wert.

gruss

[TiGü]

Zitat von EWeiss:

Zitat:

musste man echt noch auf die Größe der Kompilate achten, aber heute ist das nicht mehr relevant.

Destotrotz sehe ich keinerlei Nutzen darin warum Kompilate so dermaßen aufgebauscht werden müssen.

Ich möchte wetten, das diejenigen Leute, die sich jetzt über das ein oder andere Megabyte mehr in dem Kompilat "aufregen", genau diejenigen wären, die sich über zu lange Kompilierungszeiten beschweren würden, wenn der Delphi-Compiler so hoch optimieren würde wie der ein oder andere C++-Kompiler.

Meckern, um des Meckern willen.