Compiler Speed Pack - Features

[haentschman]

Moin...:P

Für den IDE Fix Pack gibt es ja einen ChangeLog. Ich suche verzweifelt so etwas für den Compiler Speed Pack. Was tut der genau wegen einer Validierung.

Danke für Info´s

[himitsu]

Sind diese Compiler-Bugfixe nicht im IDE Fix Pack mit enthalten?

IMHO: Also vorallem schraubt der am Unit-Cache des Compilers rum, beseitigt da mehrfache Compilate der selben Units und räumt den auch zwischendurch mal auf, damit einem der RAM nicht mehr so schnell aus geht.

[haentschman]

Hallo...

Beim Installieren des IDE Fix Pack kann man aber den Compiler Speed Pack abwählen bzw. nicht installieren. Deshalb habe ich das als getrennt betrachtet. Ich bräuchte das schon dokumentiert sonst darf ich den nicht reinnehmen, wenn unklar ist was da passiert.
Meine Meinung ist, das der Compiler als solches bleibt wie er ist und damit das Kompilat exakt genauso. Nur das "Arbeiten" des Compilers ist optimiert. :gruebel:

[himitsu]

Die beste Antwort wird bestimmt Andreas geben können.
Einfach mal anmailen (siehe Impressum) oder hier 'ne PM.


Bissl was steht da mit im Text
http://andy.jgknet.de/blog/2015/12/i...pack-6-0-beta/
http://andy.jgknet.de/blog/2014/05/i...-xe6-released/

Und ansonsten verstecken die gewünschten Infos sich halt im Changelog des IDE Fix Packs.
In der Readme und in den Blogs steht aber jeweils nur die Änderung der jeweiligen Version ... müsstest dich dann NUR mal schnell durch alle Blogs/Download/Versionen durch kämpfen.
z.B. http://andy.jgknet.de/blog/2013/11/i...-xe5-released/
Added: Hashtable for compiler directives (improves jedi.inc compilation speed) (2009-2010)
Added: Hashtable for symbol lookup in used units
...
Added: Compiler file search cache
...

[jbg]

Ursprünglich gab es nur das IDEFixPack, das sowohl IDE Bugs behob, die IDE beschleunigte und den Compiler um einiges schneller machte. Als dann der 64-Bit Compiler mit XE2 Einzug hielt, musste der gesamte Code für die Compiler-Optimierung zwei mal vorhanden sein und wich an einigen Stellen etwas ab (Felder in Records stehen an einem anderen Offset, manche Funktionen sind nicht vorhanden, dafür gibt es aber andere neue, usw.).
Damit ich nicht ganz so viel doppelten Code habe, teilte ich IDEFixPack in den IDE-Teil und zwei Compiler-Teile auf und schon war das CompilerSpeedPack geboren.

Das CompilerSpeedPack beschleunigt den Dateizugriff, den Parser/Lexer, die Unit-/Symboltabellen-Zugriffe und die Debugger Schnittstellen. Statt linearer Listen und zu linearen Listen degenerierten Hash-Tabellen (Byte als Hash ist einfach zu klein für größere Projekte) werden spezialisierte Datenstrukturen verwendet.

Das Kompilat wird dabei nicht verändert, zumindest wenn keine Bugs im IDEFixPack sind. Die BETA 6.0 ist hier beim 64-Bit Compiler wohl etwas anfällig, da sie lauter neue Optimierungen für diesen enthält. Der 32-Bit Compiler-Teil ist aber seit Jahren ohne Fehlerberichte an mich und kann wohl als stabil zu bezeichnen werden.

Was das CompilerSpeedPack genau macht, hängt von der verwendeten Delphi Version ab. Einige der Optimierungen wurden sogar bis einschließlich XE3 in den Compiler übernommen.

[haentschman]

Moin...:P

Danke Andreas...:wink:
Meinem AG geht es darum ob die Kompilate in irgend einer Form zum Original des Compilers, welcher als validiert anzusehen ist, sich unterscheiden. Wenn ja, müßten wir wenigstens wissen welche Unterschiede, und ob sie für uns relevant sind... In der Vergangenheit soll es schon mal Probleme mit dem Compiler und alten Funktionen gegeben haben. :gruebel:

Danke für deine großartige Arbeit.

[jbg]

Zitat:

Zitat von haentschman (Beitrag 1337006)

ob die Kompilate in irgend einer Form zum Original des Compilers, welcher als validiert anzusehen ist, sich unterscheiden.

Das tun sie nicht. Es wird nur an der Kompiliergeschwindigkeit herum gedoktort, nicht am generierten Code. Der bleibt gleich unoptimiert und langsam wie beim Original.

Probleme mit dem generierten Code treten nur auf, wenn das CompilerSpeedPack selbst einen Bug enthält. Bugfreiheit kann ich aber nicht garantieren, auch wenn ich schon seit mehrerer Versionen nichts mehr von Bugs gehört habe (die BETA 6.0 mal ausgeschlossen). Assembler-Code deuten und binäres Patches sind eben nicht gleich zu setzen mit Änderungen am Compiler Quellcode machen und neu kompilieren.

[haentschman]

:P Dankeschön... das sollte als Argument reichen. Schaun wir mal.