10.4 Sydney IDEFixpack kommt da noch was ?

[himitsu]

Zitat von OlliWW:

Wir kompilieren ca. 2 Mio Zeilen mit 10.4.1 in ca. 45 Sekunden.

Als "eine" EXE ginge es bei uns auch schneller (vor Jahren im XE mal ausprobiert),
aber wir kompilieren hier auch ein paar Fremdkomponenten und unser Code ist auf etwa 80 DLL/BPL/EXE verteilt.
Da geht alleine schon mehr Zeit drauf, da es "viele" Einzelprojekte sind, wo sich fast überall auch noch Eurekalog ins Kompilieren reinhängt.

[Der Bastler]

Sorry für die späte Antwort, bin überrascht, dass das es so viele Rückmeldungen gab.
Ich versuche auf ein paar Punkte einzugehen:

Uns ist aufgefallen, dass der Compiler die ersten 1,5 Mio Zeilen rel. flott durchläuft (ca. 10-20 sek.) und dann aber an manchen Stellen sehr lange festhängt. Das sind meistens Zeilen aus USES im Implementation-Teil. Aber auch Zeilen aus USES im Interface-Teil. Das verstehen wir nicht ganz. (Evt. ist ja auch die Anzeige im Compilerfenster falsch oder irreführend.) Es widerspricht auch dem was himitsu schreibt:
"Das was im USES der Implementation steht, das kann der Compiler in beliebiger Reihenfolge einbinden.

Auch werden UNITs der Implementation eventuell erst nach dem Code der Initialization geladen und bereits vor der Finalization entladen,
während die UNITs im Interface immer vor Initialization geladen und erst nach Finalization entladen werden, womit deren Funktionen dort (sicher) nutzbar sind."

Danke für den Hinweis! Hier werden wir noch mal prüfen und evt. ein paar mehr "cast's" in Kauf nehmen.


* USES-Sorter-Tool: Wir analysieren alle Abhängigkeiten unserer Units voneinander(Häufigkeit; Streuung;...) jeweils nach "interface" in "implementation" und bringen diese in die optimale Reihenfolge. Eine wichtige Regel hierbei, die für unser Projekt funktioniert:
Zuerst die Units, die keine Abhängigkeiten in unser Projekt haben (Delphi-Units,...), dann die Projekt-Units sortiert nach ihren Querabhängigkeiten und zwar die mit den MEISTEN ZUERST. (Unser Tool hat hierfür Schieberegler, mit denen man die Prioritäten der Verwendungen(verwendet / wird verwendet <=> interface / implementation) einstellen und optimieren kann.)

=> Das sind aber unsere Erfahrungswerte für SEATTLE und RIO, wir wissen nicht, ob das für andere Projekte und/oder andere Compiler gilt.

Refactoring: Ja! Immer und unbedingt! Je größer und langlebiger das Projekt umso notwendiger. Unser Projekt ist über mehr als 20 Jahre stetig gewachsen und nicht immer wurde konsequent dran geblieben - leider. Der Refactoring-Prozess ist deshalb aufwändig und oft rel. komplex und hat schon unzählige Stunden verschlungen.
Er darf nicht so viel Resourcen binden, dass inzwischen die Kunden abspringen .

Compile-Zeiten (in Delphi eigentlich "Erzeugen"-Zeiten): Ich habe Euch Richtwerte geschrieben, die auf unseren Standard-Entwickler-Rechnern - alles lokal - so auftreten (z.B. I7-7700T 2,9GHz; 16GB RAM; Win 10 Pro). Wir erzeugen in reichlich 6 min. mit IDEFixPack. Das ist ok für uns. Manche Entwickler brauchen selten zu erzeugen, meist reichen ein oder mehrere Strg+F9 hintereinander aus.
Die 40 Minuten beziehen sich auf Erzeugen ohne IDEFixPack z.B. in SYDNEY. (Ich kann Euch gern mal ein Video machen ) Virenscanner spielt keine Rolle. Aber vielleicht machen wir ja auch einen anderen grundlegenden Fehler oder wir haben falsche Einstellungen in der IDE,... ?

Viele Grüße, Lars

[dummzeuch]

Zitat von Der Bastler:

USES-Sorter-Tool: Wir analysieren alle Abhängigkeiten unserer Units voneinander(Häufigkeit; Streuung;...) jeweils nach "interface" in "implementation" und bringen diese in die optimale Reihenfolge. Eine wichtige Regel hierbei, die für unser Projekt funktioniert:
Zuerst die Units, die keine Abhängigkeiten in unser Projekt haben (Delphi-Units,...), dann die Projekt-Units sortiert nach ihren Querabhängigkeiten und zwar die mit den WENIGSTEN ZUERST. (Unser Tool hat hierfür Schieberegler, mit denen man die Prioritäten der Verwendungen(verwendet / wird verwendet <=> interface / implementation) einstellen und optimieren kann.)

=> Das sind aber unsere Erfahrungswerte für SEATTLE und RIO, wir wissen nicht, ob das für andere Projekte und/oder andere Compiler gilt.

D.h. das Tool ändert nur die Reihenfolge der Units in Uses-Liste der .DPR-Datei?

Darauf muss man erstmal kommen, ist aber definitiv plausibel.

[Delphi.Narium]

@Der Bastler

Habt Ihr mal den FileMon / ProcessExplorer mitloggen lassen, worauf Delphi beim Kompilieren zugreift, wie und wo es sich 'nen Wolf sucht?

Da sieht man dann auch alle Dateizugriffe, die ins Leere laufen, weil die gesuchte Datei an der Stelle nicht gefunden wurde und dann der Suchpfad der Reihe nach durchgegangen wird. Das kann ganz schön viel werden.

Deshalb: Suchpfade auf das wirklich erforderliche reduzieren.

Wir hatten das Thema vor einiger Zeit schonmal, eventuell hilft das weiter: https://www.delphipraxis.net/1425517-post24.html bzw. https://www.delphipraxis.net/199685-...en-finden.html

[TurboMagic]

Die Integration weitere Teile des Fixpacks ist m.W. am Laufen...
Geht halt nur nicht auf einmal, da das nicht 1:1 übernommen werden kann/sollte.

[jbg]

Zitat von TurboMagic:

Die Integration weitere Teile des Fixpacks ist m.W. am Laufen...
Geht halt nur nicht auf einmal, da das nicht 1:1 übernommen werden kann/sollte.

Was man recht "schnell" machen könnte, wären die Einführung von HashTables als Ersatz oder als Cache für die vielen LinkedLists im Compiler. Aber bitte nicht wieder so wie bei XE2, wo HashTable eingeführt wurden, die mehr Zeit mit dem HashTable-Overhead verbringen, als mit den eigentlichen Daten. Man muss nicht Speicher reservieren und durch die Gegend kopieren, wenn man einen Eintrag sucht.

Dann gibt es noch die Einzel-Funktions-Beschleunigungen, bei denen einzelne Funktionen durch schnellere ersetzt wurden oder die für den Fall, der am meisten Eintritt, optimiert weurden. Die lassen sich (theoretisch) sogar Unittesten.

Auch recht "einfach" lassen sich die "Invarianten Code aus Schleifen entfernen" Patches umsetzen. Das macht vor allem den WIn64 Compiler einen Ticken schneller.


Kompliziert wird es bei den IDEFixPack Patches, die algorithmische Änderungen durchführen oder die Funktionsübergreifend arbeiten (in einer Funktion Informationen sammeln und in einer späteren Funktion diese nuten).

[stahli]

Zitat von Delphi.Narium:

@Der Bastler

Habt Ihr mal den FileMon / ProcessExplorer mitloggen lassen, worauf Delphi beim Kompilieren zugreift, wie und wo es sich 'nen Wolf sucht?

Da sieht man dann auch alle Dateizugriffe, die ins Leere laufen, weil die gesuchte Datei an der Stelle nicht gefunden wurde und dann der Suchpfad der Reihe nach durchgegangen wird. Das kann ganz schön viel werden.

Deshalb: Suchpfade auf das wirklich erforderliche reduzieren.

Wir hatten das Thema vor einiger Zeit schonmal, eventuell hilft das weiter: https://www.delphipraxis.net/1425517-post24.html bzw. https://www.delphipraxis.net/199685-...en-finden.html

Aber Vorsicht vor "Pfade bereinigen" (oder wie das hieß).
Früher hat das jedenfalls mal Delphi lahm gelegt...

[Delphi.Narium]

Im FileMon kann man gut sehen, wo Dateien gesucht werden und wo sie gefunden werden.

Wenn nun in den Pfaden Verzeichnisse sind, in denen grundsätzlich nichts gefunden wird, kann man die schon bereinigen.

Die Verzeichnisse, in denen Delphi "sein eigenes Zeug" findet. lässt man natürlich in den Suchpfaden drinne, auch wenn bei einem Projekt konkret eventuell mal nix von dort benötigt wird.

Und:
Unter Pfade bereinigen meine ich eine menschliche, individuelle Bereinigung, nicht die, die die IDE selbst anbietet.

[himitsu]

Beim Pfad-Bereinigen gab es das Problem, dass Pfade mit Variablen gelöscht wurden, weil die Variablen nicht durch Platzhalter ersetzt und erst damit dann gesucht wird.

Das betrifft z.B. die Platform/Compiler-abhängigen Pfade.

[Der Bastler]

Zitat von Delphi.Narium:

@Der Bastler

Habt Ihr mal den FileMon / ProcessExplorer mitloggen lassen, worauf Delphi beim Kompilieren zugreift, wie und wo es sich 'nen Wolf sucht?

Da sieht man dann auch alle Dateizugriffe, die ins Leere laufen, weil die gesuchte Datei an der Stelle nicht gefunden wurde und dann der Suchpfad der Reihe nach durchgegangen wird. Das kann ganz schön viel werden.

Deshalb: Suchpfade auf das wirklich erforderliche reduzieren.

Wir hatten das Thema vor einiger Zeit schonmal, eventuell hilft das weiter: https://www.delphipraxis.net/1425517-post24.html bzw. https://www.delphipraxis.net/199685-...en-finden.html

Ja. Keine Units, die nicht verwendet werden, einbinden. Das kann man mit diversen Tools herausfinden (z.B. mit ICARUS; der sagt auch, welche Units von "interface" nach "implementation" geschoben werden können).