10.4 Sydney IDEFixpack kommt da noch was ?

[Der Bastler]

Wir hoffen auch auf die Compilerbeschleunigung. Das ist für uns das k.o.-Kriterium für den Kauf neuer Delphi-Versionen.
Wir haben derzeit knapp 3 Mio. selbst geschriebener Code-Zeilen und noch einige Imports.
Im RIO mit IDEFixPack sind wir im Optimalfall bei reichlich 6min. Sydney braucht ca. 40 min. (Ist damit aber schneller als RIO ohne IDEFixPack)

Ein wichtiger Trick für das Optimum der Compilerzeiten liegt in der richtigen Reihenfolge der Units im USES. Wir haben hier ewig probiert und optimiert und haben über 30 Minuten rausgeholt.
Wir haben extra ein Tool geschrieben, dass uns die USES sortiert. Beim programmieren landen Neue i.d.R. nicht an der optimalen Stelle.
Evt. hilft Euch das weiter...

Viele Grüße, Lars

[woodie]

Zitat von Der Bastler:

Wir haben extra ein Tool geschrieben, dass uns die USES sortiert. Beim programmieren landen Neue i.d.R. nicht an der optimalen Stelle.

Was ist die optimale Reihenfolge für den Compiler? Wie findet eurer Tool das automatisch raus?

[dummzeuch]

Zitat von woodie:

Zitat von Der Bastler:

Wir haben extra ein Tool geschrieben, dass uns die USES sortiert. Beim programmieren landen Neue i.d.R. nicht an der optimalen Stelle.

Was ist die optimale Reihenfolge für den Compiler? Wie findet eurer Tool das automatisch raus?

Genau dies würde mich auch brennend interessieren.

[OlliWW]

Wahrscheinlich entscheidet das Tool nur ob es in der Implementatation oder im Interface landet. Sowas können aber meines Erachtens nach auch viele andere Tools bereits.

[freimatz]

Zitat von Der Bastler:

Ein wichtiger Trick für das Optimum der Compilerzeiten liegt in der richtigen Reihenfolge der Units im USES. Wir haben hier ewig probiert und optimiert und haben über 30 Minuten rausgeholt.
...
Evt. hilft Euch das weiter...

Viele Grüße, Lars

Danke. Noch mehr würde es helfen wenn Du uns verrätst, was denn die richtige Reihenfolge ist.

[himitsu]

Darum auch meine Empfehlung möglichst nur das USES im Interface zu benutzen.

Dort steht dir Reihenfolge fest, also immer in der Reihenfolge, wie es im Code steht.
* erste Unit
* dann das was in dieser Unit steht
* dann zweite Unit (falls nicht bereits in untergeordneten Units geladen)
* usw.

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.
Selbes gilt für Codes der Class-Constructor und Class-Destructor.

[HeZa]

Zitat von himitsu:

Darum auch meine Empfehlung möglichst nur das USES im Interface zu benutzen.

Dort steht dir Reihenfolge fest, also immer in der Reihenfolge, wie es im Code steht.
* erste Unit
* dann das was in dieser Unit steht
* dann zweite Unit (falls nicht bereits in untergeordneten Units geladen)
* usw.

Das was im USES der Implementation steht, das kann der Compiler in beliebiger Reihenfolge einbinden.

wenn ich also die Units A, B und C habe und alle 3 den Bezeichner X definieren und ich in der implementation uses A, B, C angebe und X in meiner Unit verwende, dann verwende ich unter Umständen das X aus B oder A?

*Kopfkratz*

[himitsu]

Zitat von HeZa:

wenn ich also die Units A, B und C habe und alle 3 den Bezeichner X definieren und ich in der implementation uses A, B, C angebe und X in meiner Unit verwende, dann verwende ich unter Umständen das X aus B oder A?

*Kopfkratz*

Ja, aber so lange B oder C nicht auch in A vorkommen, wird dennoch A von deiner Liste als Erstes geladen/initialisiert.

Deine Reihenfolge, aber natürlich die Abhängigkeiten zuerst.
Wenn A etwas benötigt, dann muß das ja zuerst da sein.



Dennoch bleibt insgesamt diese Reihenfolge konsistent und quasi nachvollziehbar.
Es passiert somit nicht, dass es plötzliche eine andere Reihenfolge ist, wenn du 5 Minuten später nochmal kompilierst.
(abgesehn von dem Zeugs in der Implementation)

Fehler, z.B. durch fehlende Initialisierung, sind dann nicht mal da und mal weg.
Ich hatte mal so einen Fall, dass es über Komandozeile kompiliert einen Fehler gab, aber in der IDE kompiliert war der plötzlich weg, womit er beim Debuggen nicht so schnell zu finden war.

[OlliWW]

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

Wir haben in den letzten Jahren sehr viel Zeit darauf verwendet Units zu trennen, zirkuläre Referenzen zu lösen und halten die "uses" dauerhaft "sauber". Wir lassen regelmäßig vom CNPack und anderen static analyzern überprüfen, ob wir noch etwas verbessern können.

Kompiliert wird auf VMs die auf einem Intel Xeon Gold mit 3.0 Ghz laufen.

[Rollo62]

Zitat von OlliWW:

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

Wir haben in den letzten Jahren sehr viel Zeit darauf verwendet Units zu trennen, zirkuläre Referenzen zu lösen und halten die "uses" dauerhaft "sauber". Wir lassen regelmäßig vom CNPack und anderen static analyzern überprüfen, ob wir noch etwas verbessern können.

Kompiliert wird auf VMs die auf einem Intel Xeon Gold mit 3.0 Ghz laufen.

+1