Das Programm wird zu groß

[Stevie]

Zitat von Uwe Raabe:

Allerdings wird innerhalb der Delphi-DCUs selbst mittlerweile immer mehr RTTI wirklich benutzt. So ist das gesamte Component-Streaming in System.Classes ohne RTTI gar nicht mehr voll funktionsfähig (und wer will schon auf System.Classes verzichten). Insofern ist es auch keine Option mehr, in den Standard-DCUs das RTTI abzuschalten.

Doch, ist und sollte es. Schau dir mal an, wie viel nutzloser Klump in einer Exe landet, wenn du nur ne VCL Anwendung machst und da mal nen QuantumGrid drauf packst, oder eine leere FMX Anwendung. Mehrere Megabyte durch duzende verschiedenen TList<...> obwohl sie ja die meist gebrauchten Methoden seit XE7 inlined haben. Aber da für die ganzen Collections nunmal RTTI an ist, werden die alle in die Exe gezogen. Ich hab bisher nicht genau analysiert, wie die letztlich angeordnet sind, aber der Instruction Cache der CPU wird sich bestimmt nicht drüber freuen.

[Rollo62]

[QUOTE=Stevie;1443980]

Zitat von Uwe Raabe:

duzende verschiedenen TList<...> obwohl sie ja die meist gebrauchten Methoden seit XE7 inlined haben. Aber da für die ganzen Collections nunmal RTTI an ist,

In Spring4D wird ja auch die System.Generics.Collections eingebunden, also wäre das Problem mit TList<> dort auch akut, oder gibt es eine Alternative dazu die sich mit Spring4D verträgt ?

[Rolf Frei]

Zitat von Uwe Raabe:

Zitat von Rolf Frei:

Die ganze Delphi Library wird ja nicht neu kompiliert und daher wird das da auch keine Auswirkung haben. Die Delphi DCU's sind ja so kompiliert, dass RTTI geht. Würde man die ganze Library noch neu kompilieren, würde die Exe Grösse nochmals massiv verkleienert. Mit der Einführung der neuen RTTI sind ja leider auch die exes in der Grösse explodiert und wenn man selber garkein RTTI braucht ist das schon sehr ärgerlich.

Allerdings wird innerhalb der Delphi-DCUs selbst mittlerweile immer mehr RTTI wirklich benutzt. So ist das gesamte Component-Streaming in System.Classes ohne RTTI gar nicht mehr voll funktionsfähig (und wer will schon auf System.Classes verzichten). Insofern ist es auch keine Option mehr, in den Standard-DCUs das RTTI abzuschalten.

Ja das weiss ich ja. Nur hat eben der Schalter im DPR keine Auswirkung auf die gelinkten Delphi dcu's sondern nur auf die eigenen Units die neu kompiliert werden.

[Stevie]

Zitat von Rollo62:

Zitat von Stevie:

duzende verschiedenen TList<...> obwohl sie ja die meist gebrauchten Methoden seit XE7 inlined haben. Aber da für die ganzen Collections nunmal RTTI an ist,

In Spring4D wird ja auch die System.Generics.Collections eingebunden, also wäre das Problem mit TList<> dort auch akut, oder gibt es eine Alternative dazu die sich mit Spring4D verträgt ?

Spring4D nutzt nur an einigen wenigen Stellen System.Generics.Collections und zwar dort, wo man aufgrund des ich nenns mal "Henne-Ei"-Problems nicht die Spring.Collections nutzen kann, z.B. in der Spring.pas. Zudem sind schon seit langem die ganzen Collections eigene Implementierungen (früher waren es alles nur Wrapper um die System.Generics.Collections Klassen) - mit 2.0 wurde die letzte dieser (das Dictionary) abgelöst.

Zudem hab ich für 2.0 massiv daran gearbeitet, eben diesen Code Bloat zu bekämpfen - RTTI abgeschaltet, wo es geht, interne Architekturen umgestellt und einige Tricks, um identische Generics nicht zu duplizieren. Dieser wirkt sich nämlich nachweisbar nicht nur auf die Größe der Binary aus, sondern auch auf die Compilezeit und den Speicherverbrauch des Compilers - mal ein paar Zahlen auszugsweise: im Vergleich 1.2.2 zu 2.0 (Stand alpha.2) haben sich die Compilezeiten unter Win32 bis zu viermal verbessert - ein Referenzprojekt was ich dazu nutzte ging von über 60 Sekunden für einige 100K LoC wo eine Menge von Generics genutzt wurden auf unter 15 Sekunden und die Binarygröße hat sich in ähnlicher Größenordnung verringert (natürlich je nach Code und Anwendung unterschiedlich).

Mehr zu der ganzen Thematik werd ich dieses Jahr auf der EKON erzählen.

[Rollo62]

Danke für die info, gut zu wissen.