DLL mit FPC/Codetyphon erheblich kleiner als unter Delphi

[Benedikt Magnus]

Klar, mein XE5 ist auch nicht mehr das jüngste Delphi, aber das hat mich dann doch etwas verwundert, denn bisher kannte ich FPC nur mit vergleichsweise großen Kompilaten.

Folgendes ist mir mit FPC 3.1.1 neuerdings aufgefallen:
Ich habe unter Delphi XE eine ganz einfache DLL(System.Classes und System.SysUtils eingebunden) erstellt. Gesamtgröße, ganz normal, unter Win64 Release: 1.582 KB.
Die DLL erstelle ich ebenfalls unter Linux mit CodeTyphon. Zum Spaß habe ich dort mal das Crosscompiling für Win64 aufgesetzt. Und was kam raus? Die gleiche DLL mit FPC kompiliert: 230 KB!
Nicht nur, dass das FPC-Kompilat kleiner ist als das von Delphi, nein, sogar fast siebenmal kleiner.

Kann mir das einer erklären? Also nicht, dass das ein Problem darstellen würde, es wundert mich nur sehr. Hat es seit XE5 da jede Menge erstaunlicher Entwicklungen gegeben oder hat FreePascal nun Delphi doch endlich überholt?

Ich glaube, ich mache mal ein paar Geschwindigkeitstests...

[Uwe Raabe]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1337498)

hat FreePascal nun Delphi doch endlich überholt?

Wieso überholt? Wenn ich das richtig sehe, muss FreePascal noch einige KByte and Code aufholen, oder?

[Benedikt Magnus]

Wie aufholen?
Delphi: 1.582 KB
FreePascal: 230 KB
Bei gleicher DLL.

[jaenicke]

In der mit Delphi kompilierten Version steckt eben entsprechend mehr Funktionalität. Da ändert es auch nichts daran die gleichen Units einzubinden, weil diese eben nicht gleich sind.

[Benedikt Magnus]

Siebenmal mehr Funktionalität? Was denn?
Und wenn das alles nicht gebraucht wird, fragt sich, warum Delphi es dann überhaupt in das Kombilat steckt?

[Uwe Raabe]

Um es auf andere Art zu zeigen: Eine leere DLL mit SysUtils und Classes in Delphi 7 hat knapp 90 kB. Ist Delphi 7 damit ein Fortschritt gegenüber Delphi XE5 oder FreePascal?

[Uwe Raabe]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1337507)

Siebenmal mehr Funktionalität? Was denn?

Ja, kommt ungefähr hin.

Zitat:

Zitat von Benedikt Magnus (Beitrag 1337507)

Und wenn das alles nicht gebraucht wird, fragt sich, warum Delphi es dann überhaupt in das Kombilat steckt?

Warum tut FreePascal es denn?

[Benedikt Magnus]

Ich war selbst bisher immer der Meinung, dass Delphi FreePascal noch um Meilen voraus ist. Aber sag mir doch bitte, welche Mengen Funktionen ich in Delphi erwarten kann, die es in FreePascal nicht gibt? Klar, mir fällt da das ein oder andere ein (anonyme Methoden z.B.), aber was denn Großartiges, das einen solchen Unterschied erklären könnte?

Zu Delphi 7:
Natürlich nicht. Aber zwischen Delphi 7 und XE5 etc. ist schon ein erheblicher Unterschied. Diesen sehe ich nicht zu FreePascal. Außerdem mein Kommentar zur Geschwindigkeit.

[milos]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1337510)

Ich war selbst bisher immer der Meinung, dass Delphi FreePascal noch um Meilen voraus ist. Aber sag mir doch bitte, welche Mengen Funktionen ich in Delphi erwarten kann, die es in FreePascal nicht gibt? Klar, mir fällt da das ein oder andere ein (anonyme Methoden z.B.), aber was denn Großartiges, das einen solchen Unterschied erklären könnte?

Zu Delphi 7:
Natürlich nicht. Aber zwischen Delphi 7 und XE5 etc. ist schon ein erheblicher Unterschied. Diesen sehe ich nicht zu FreePascal. Außerdem mein Kommentar zur Geschwindigkeit.

Es geht dabei ja nicht um Sprachfeatures sondern eher um den Funktionsumfang die die Units eben mitliefern. Vergleiche sie doch mal in XE5 und Lazarus.

Ansonsten kannst du ja auch versuchen wirklich 100% den gleichen Code zu kompillieren und nicht nur Units mit dem selben Namen einzubinden und dann einen richtigen Vergleich machen :wink:

Freundliche Grüsse

[Uwe Raabe]

Zitat:

Zitat von milos (Beitrag 1337512)

Ansonsten kannst du ja auch versuchen wirklich 100% den gleichen Code zu kompillieren und nicht nur Units mit dem selben Namen einzubinden

Das wird ebenfalls nicht viel bringen. Der Code kann sich ja auch nur auf den gemeinsamen Nenner beziehen und lässt vermutlich in beiden Systemen noch einiges brach liegen.

Vielleicht sollte man sich erstmal fragen, was diese Größe der DLL als Vergleichswert überhaupt aussagt. Wie schon in meiner ersten Antwort angedeutet, ist es erstmal eine Ansammlung von compiliertem Code. Es sagt insbesondere nichts über die Qualität, den Funkionsumfang oder die Effizienz dieses Codes aus. Wenn ich nur die Größe der DLL betrachte, dann hat Delphi 7 hier immer noch die Nase vorn. Trotzdem vermeide ich es weitestgehend, damit zu arbeiten und gebe aktuell Delphi 10.1 Berlin den Vorzug. Hier hat die leere DLL übrigens 968704 Bytes (RELEASE).

[EWeiss]

Ich frage mich warum überhaupt unnötiger Mist (Sorry)
in einer DLL\EXE mit ein kompiliert wird obwohl die DLL mit den Diversen Funktionen überhaupt nicht arbeitet.
In anderen Developer Umgebungen kann man bestimmte Schalter setzen welche das Verhindert.

Zwischen D2006 und D2010 hat sich meine DLL um gut 50% vergrößert ohne irgendeine Zeile im Code selbst zu verändern.
Es hat den Anschein als wenn die kompletten Units die man eingebunden hat vollständig mit ein kompiliert werden
und nicht nur die Teile davon die in Verwendung sind.


gruss

[Delphi-Laie]

Zitat:

Zitat von jaenicke (Beitrag 1337506)

In der mit Delphi kompilierten Version steckt eben entsprechend mehr Funktionalität.

Die brachliegt.

Beide DLLs tun hoffentlich das gleiche, nämlich das, was im Quelltext steht. Der Rest in der von Delphi erzeugten DLL ist nicht abrufbar.

[Delphi-Laie]

Zitat:

Zitat von EWeiss (Beitrag 1337514)

Ich frage mich warum überhaupt unnötiger Mist (Sorry)
in einer DLL\EXE mit ein kompiliert wird obwohl die DLL mit den Diversen Funktionen überhaupt nicht arbeitet.
In anderen Developer Umgebungen kann man bestimmte Schalter setzen welche das Verhindert.

Zwischen D2006 und D2010 hat sich meine DLL um gut 50% vergrößert ohne irgendeine Zeile im Code selbst zu verändern.

Das Phänomen tendenziell immer größerer Compilate existiert leider schon seit Turbo-Pascal-Zeiten so und wurde nie ernsthaft angegangen.

Zitat:

Zitat von EWeiss (Beitrag 1337514)

Es hat den Anschein als wenn die kompletten Units die man eingebunden hat vollständig mit ein kompiliert werden
und nicht nur die Teile davon die in Verwendung sind.

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

[EWeiss]

Zitat:

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

Nein?

Hmm.. also der unterschied ist schon krass von 2010 > XE fast 1 MB mehr wohl bemerkt gleiche DLL gleicher Code.
War einer der gründe weshalb ich gut und gern auf XE verzichtet habe.

Auch wenn in der Heutigen zeit die Größe einer Datei bei der Kapazität der Festplatten keine große rolle mehr spielt
wundern sich die Anwender trotzdem darüber das die Datei bei gleicher API ohne Änderung plötzlich 1 MB mehr hat.

Theoretisch sollte meine DLL also Max. 250 KB sein (D7) hat aber > 2 MB nach einer Test Kompilierung unter XE.
Was rechtfertigt also diese enorme Vergrößerung.

gruss

[Neutral General]

Ich finde eure Argumentation total unsinnig.

Die einstelligen MB-Unterschiede machen heutzutage überhaupt nichts aus. Das hat quasi keinen messbaren negativen Einfluss auf irgendwas.
Denn wie schon erwähnt wurde ist in Delphi eben ne ganze Menge mehr dabei als in FPC.
Es ist als würde man argumentieren dass ein Smart einem Audi R8 überlegen ist, weil der Smart weniger Benzin verbraucht :roll:

Ich kann euch beruhigen: FPC wird Delphi in absehbarer Zeit nicht überholen :stupid:

[EWeiss]

Zitat:

Ich finde eure Argumentation total unsinnig.

Jo. Solange es um FPC/Codetyphon via Delphi geht. Unterschiedliche Compiler halt.

Das rechtfertigt aber noch lange nicht das bei unterschiedlichen Delphi Umgebungen (Versionen)
ein und der gleiche Code so hoch gepuscht wird was die Größe angeht.
Das hat nichts mit Unsinn zu tun es ist Tatsache.

JA OT!


gruss

[hoika]

Hallo,
bringen die RTTI-Compilerschalter nicht ein bisschen?


Heiko

[EWeiss]

Zitat:

Zitat von hoika (Beitrag 1337520)

Hallo,
bringen die RTTI-Compilerschalter nicht ein bisschen?


Heiko

Nein bringen nichts :oops: War einer meiner ersten versuche.
Na egal wollte das nur mal anmerken, wir leben nun mal in einer Verschwenderischen Zeit.
Es gibt keinen Vorteil, gewinn oder hat irgendeinen Einfluss auf die Funktionsweise das die Datei nun 1,5 MB größer ist.


gruss

[Uwe Raabe]

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.

Kann auch nicht, da die RTL-Units ja bereits im compilierten Zustand vorliegen.

Mein Fazit dieser ganzen Diskussion: Wer eine DLL erzeugen will, die nichts macht, sollte Delphi 7 oder älter (aber nicht Delphi 1, das erzeugt nur 16 Bit) nehmen, dann nimmt sie auch nicht soviel Platz auf der Festplatte ein, lässt aber trotzdem keine ihrer Funktionalitäten vermissen. Ganz Verwegene können sie ja auch ganz weglassen und erzeugen eine 0 Byte große Datei, die sie einfach so nennen.

[hstreicher]

Die Frage ist doch wieso soll Programmierleistung auf etwas verwendet werden (also das rauswerfen nicht verwendeter Proceduren aus den Units) was ausser minimaler Kosmetik nichts bringt , da gibt es wichtigeres


(Bei der Programmierung für Mobilgeräten mit kleinem Speicher (Smartwatches u.s.w) gilt das vorgesagte ausdrücklich nicht!)

[Benedikt Magnus]

Zitat:

Zitat von Uwe Raabe (Beitrag 1337530)

Mein Fazit dieser ganzen Diskussion: Wer eine DLL erzeugen will, die nichts macht, sollte Delphi 7 oder älter (aber nicht Delphi 1, das erzeugt nur 16 Bit) nehmen, dann nimmt sie auch nicht soviel Platz auf der Festplatte ein, lässt aber trotzdem keine ihrer Funktionalitäten vermissen. Ganz Verwegene können sie ja auch ganz weglassen und erzeugen eine 0 Byte große Datei, die sie einfach so nennen.

Naja, jetzt wirds aber...
Zuallerst sprach ich von Anfang an von einer kleinen, nicht von einer leeren DLL. Des Weiteren kann man nicht einfach einen Kritikpunkt mit "dann nutzt doch eine alte Version" abspeisen.
Ich werde aufgrund andere Faktoren weiterhin Delphi verwenden, keine Frage, das hier sollte auch gar keine Diskussion werden, ob FreePascal oder Delphi besser ist, sondern nur meine Frage beantworten, warum FreePascal bei gleicher Funktionalität ein sehr viel kleineres Kompilat erzeugen kann als Delphi.
Die Antwort ist dann wohl, wie ich aus deinen Kommentaren ableiten kann, dass Embarcadero sich einfach nicht herblässt, so etwas Unbedeutendes zu optimieren. Habe ich das richtig verstanden?

[P_G]

Man kann die Sache auch noch von einem anderen Standpunkt aus betrachten:
Ich habe kürzlich spaßeshalber ein Delphi XE5 Programm in Lazarus 1.6 importiert. Das Delphi-Kompilat ist nicht ganz 1 MB größer als das von Lazarus. Interessant ist es aber, wenn man sich die laufenden Exe's im Arbeitsspeicher ansieht. Hier ist das Delphi-Kompilat rund 2 MB kleiner, als das Lazarus-Kompilat. Von der Geschwindigkeit her sind beide übrigens mehr oder weniger identisch...

[EWeiss]

Zitat:

Die Antwort ist dann wohl, wie ich aus deinen Kommentaren ableiten kann, dass Embarcadero sich einfach nicht herblässt, so etwas Unbedeutendes zu optimieren.

Nehme ich auch an.

Zumindest haben sie deshalb schon mal einen Käufer weniger >= XE
Warum soll ich mir unnötigen Mist in meine Projekte mit ein kompilieren was nicht nötig ist.
Sagte ja schon bringt absolut keine Vorteile in welcher Art auch immer.

Hat schon seinen Grund warum viele noch mit D7 unterwegs sind. :)

gruss

[jaenicke]

Zitat:

Zitat von Delphi-Laie (Beitrag 1337515)

Beide DLLs tun hoffentlich das gleiche, nämlich das, was im Quelltext steht. Der Rest in der von Delphi erzeugten DLL ist nicht abrufbar.

So einfach ist es nicht. Der Compiler kann nicht feststellen ob zum Beispiel über die RTTI Codeteile ausgeführt werden. Dazu kommt dass zum Beispiel Objekte wie Application oder Screen initialisiert werden egal ob sie der Benutzer benutzt oder nicht.

Um das vollständig zu lösen, müsste der Compiler alles verstehen was in dem Programm passiert. Das ist aber Stand heute nicht möglich.

[ralfstocker]

Es ist ganz einfach. Der FPC Compiler macht einfach die bessere Analyse. Er lässt einfach mehr Sachen, die man nicht braucht, weg. Der Delphi Compiler hat sich seit Delphi 2 (1997) in dem Punkt nicht geändert. Ein weiterer wichtiger Punkt ist der generierte Code von FPC. Der ist einfach schlanker und direkter. Bei Delphi gibt es Tonnen von unnötigen Register saves und restores, die den Code langsam machen und die EXE/DLL aufblähen.

[EWeiss]

Zitat:

Das ist aber Stand heute nicht möglich.

Klar ist das möglich nur nicht mit Delphi..

C++
- Full optimization (/Ox)
- Favor small code (/Os)

mehr muss man nicht sagen..

gruss

[jaenicke]

C++ kennt aber auch keine Reflection, d.h. Methoden, die nicht im Code angesprochen werden, können auch nicht ausgeführt werden. In Delphi hingegen kannst du die RTTI benutzen um auch z.B. Methoden eines Records auszuführen usw., die nirgends im Code verwendet werden.

Außerdem ist der C++ Compiler eben auch deutlich langsamer als der von Delphi, natürlich wird in der zusätzlichen Zeit auch etwas gemacht.

Natürlich könnte man auch die Units in Delphi umschreiben, damit nicht mehr so viel automatisch geladen oder angesprochen wird. Aber genau dass ich vieles einfach so benutzen kann und zur Verfügung habe, finde ich an Delphi ja besser als eben z.B. an C++.

[jbg]

Zitat:

Zitat von jaenicke (Beitrag 1337544)

Natürlich könnte man auch die Units in Delphi umschreiben, damit nicht mehr so viel automatisch geladen oder angesprochen wird. Aber genau dass ich vieles einfach so benutzen kann und zur Verfügung habe, finde ich an Delphi ja besser als eben z.B. an C++.

Um beim Beispiel Application und Screen zu bleiben. Man müsste das Erstellen der Objekte einfach nur in den Klassen-Konstruktor (gibt es seit Delphi 2010) verschieben. Und schon könnte man Vcl.Forms einbinden ohne dass TApplication und TScreen im Kompilat laden, wenn man auf keine der Funktionalitäten direkt oder indirekt zugreift.
Idera/Embarcadero müsste halt mal die initialization und finalization der Units aufräumen (oder entfernen).

Es wäre auch mal von Vorteil, wenn z.B. das gesamte DFM Streaming aus TStream herausgelöst werden würde. Ein Konsolenprogramm, das Streams benutzt braucht in der Regel kein DFM Streaming.

Aber bei der RTL/VCL ist diese "jeder nutzt jeden" zum Glück nicht ganz so schlimm ausgeprägt wie es bei der FMX ist. Da hat man gefühlt schon fast 80% allen FMX Codes in der Anwendung zu haben, wenn man nur eine FMX Unit einbindet.

[jaenicke]

Zitat:

Zitat von ralfstocker (Beitrag 1337537)

Ein weiterer wichtiger Punkt ist der generierte Code von FPC. Der ist einfach schlanker und direkter. Bei Delphi gibt es Tonnen von unnötigen Register saves und restores, die den Code langsam machen und die EXE/DLL aufblähen.

Ein konkretes Beispiel wäre schön. Wenn ich so den generierten Code vergleiche, kann ich davon nichts sehen. Ein einfaches Beispiel:

Delphi-Quellcode:

var
  a: string;
  b: Integer;
begin
  b := 42;
  a := IntToStr(b);
  ShowMessage(a);
end;

Delphi:

Code:

Unit93.pas.30: begin
00000000006B6B80 55               push rbp
00000000006B6B81 4883EC30         sub rsp,$30
00000000006B6B85 488BEC           mov rbp,rsp
00000000006B6B88 48C7452800000000 mov qword ptr [rbp+$28],$0000000000000000
00000000006B6B90 48894D40         mov [rbp+$40],rcx
00000000006B6B94 48895548         mov [rbp+$48],rdx
00000000006B6B98 90               nop
Unit93.pas.31: b := 42;
00000000006B6B99 C745242A000000   mov [rbp+$24],$0000002a
Unit93.pas.32: a := IntToStr(b);
00000000006B6BA0 488D4D28         lea rcx,[rbp+$28]
00000000006B6BA4 8B5524           mov edx,[rbp+$24]
00000000006B6BA7 E88493D7FF       call IntToStr
Unit93.pas.33: ShowMessage(a);
00000000006B6BAC 488B4D28         mov rcx,[rbp+$28]
00000000006B6BB0 E89B3BF3FF       call ShowMessage
00000000006B6BB5 90               nop
Unit93.pas.34: end;
00000000006B6BB6 488D4D28         lea rcx,[rbp+$28]
00000000006B6BBA E8217BD5FF       call @UStrClr
00000000006B6BBF 488D6530         lea rsp,[rbp+$30]
00000000006B6BC3 5D               pop rbp
00000000006B6BC4 C3               ret

Lazarus / FPC:

Code:

unit1.pas:37                              begin
000000010002C390 55                       push   %rbp
000000010002C391 4889e5                   mov    %rsp,%rbp
000000010002C394 488d6424c0               lea    -0x40(%rsp),%rsp
000000010002C399 48894df0                 mov    %rcx,-0x10(%rbp)
000000010002C39D 488955f8                 mov    %rdx,-0x8(%rbp)
000000010002C3A1 48c745e800000000         movq   $0x0,-0x18(%rbp)
000000010002C3A9 90                       nop
unit1.pas:38                              b := 42;
000000010002C3AA c745e02a000000           movl   $0x2a,-0x20(%rbp)
unit1.pas:39                              a := IntToStr(b);
000000010002C3B1 8b45e0                   mov    -0x20(%rbp),%eax
000000010002C3B4 488d4de8                 lea    -0x18(%rbp),%rcx
000000010002C3B8 89c2                     mov    %eax,%edx
000000010002C3BA e8c11a0200               callq  0x10004de80 <SYSUTILS_$$_INTTOSTR$LONGINT$$ANSISTRING>
unit1.pas:40                              ShowMessage(a);
000000010002C3BF 488b4de8                 mov    -0x18(%rbp),%rcx
000000010002C3C3 e828201100               callq  0x10013e3f0 <SHOWMESSAGE>
unit1.pas:37                              begin
000000010002C3C8 90                       nop
000000010002C3C9 4889e9                   mov    %rbp,%rcx
000000010002C3CC e89fffffff               callq  0x10002c370 <fin$0>
unit1.pas:41                              end;
000000010002C3D1 90                       nop
000000010002C3D2 488d6500                 lea    0x0(%rbp),%rsp
000000010002C3D6 5d                       pop    %rbp
000000010002C3D7 c3                       retq

[Benedikt Magnus]

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

[ralfstocker]

Danke!

Zitat:

Zitat von Benedikt Magnus (Beitrag 1337569)

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:

Zitat von EWeiss (Beitrag 1337617)

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. :roll:

[Daniel]

Zitat:

Zitat von TiGü (Beitrag 1337619)

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.

"Größere Kompilate vs. kürzere Kompilier-Zeit aufgrund weniger Optimierung": Unser Prof sprach vom "Elend-Erhaltungssatz". Seiner Ansicht nach bliebe die Menge an Elend stest die selbe: Entweder Du erhältst kleinere Kompilate und wartest dafür länger oder Du wartest nicht so lang und hast dann größere Kompilate.

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.

[EWeiss]

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 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?
Es geht doch nur noch um Zeit und Geld.
Allein die Bitcoins zu generieren verbraucht TeraWatt an Strom auf der anderen Seite verdursten Menschen weil sie nicht mal über einen Brunnen für ihr Dorf verfügen.

Zitat:

Meckernm um des Meckern willen.

Logisch wenn man nicht über den Rand des Tellers hinweg schauen will.

gruss

[TiGü]

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:

Es wäre aber definitiv eine Verschwendung von Ressourcen seitens der Kompiler-Entwickler, wenn sie jetzt Mannmonate/-jahre in die Optimierung stecken würden.
Es würde sich nämlich nicht lohnen (für den typischen Delphi-Entwickler).
Die Bereiche in der Softwareentwicklung, in denen das relevant ist, verwenden eh schon was anderes (siehe oben den Beitrag von TRomano) als technologische Lösung.

Zitat:

Zitat von EWeiss (Beitrag 1337623)

Zitat:

Meckernm um des Meckern willen.

Logisch wenn man nicht über den Rand des Tellers hinweg schauen will.

Welche alte Delphi-Version verwendest du nochmal?
Und was kann die alles nicht im Vergleich zu Seattle/Berlin?

[EWeiss]

Zitat:

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

Mal zig Milliarden? Nein?

Zitat:

Und was kann die alles nicht im Vergleich zu Seattle/Berlin?

Und?
Da sollte man sich erst mal die Frage stellen ob man das denn alles braucht.

gruss