DLL mit FPC/Codetyphon erheblich kleiner als unter Delphi

[Uwe Raabe]

Zitat von Benedikt Magnus:

Siebenmal mehr Funktionalität? Was denn?

Ja, kommt ungefähr hin.

Zitat von Benedikt Magnus:

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 von 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.

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

Freundliche Grüsse

[Uwe Raabe]

Zitat von milos:

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 von 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.

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

Zitat von EWeiss:

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

[hoika]

Hallo,
bringen die RTTI-Compilerschalter nicht ein bisschen?


Heiko

[EWeiss]

Zitat von hoika:

Hallo,
bringen die RTTI-Compilerschalter nicht ein bisschen?


Heiko

Nein bringen nichts 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 von EWeiss:

Zitat von hoika:

Hallo,
bringen die RTTI-Compilerschalter nicht ein bisschen?


Heiko

Nein bringen nichts 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.