10.4 Sydney IDEFixpack kommt da noch was ?

[jaenicke]

Wir kommen auf einer CPU mit einer Einzelkernleistung von ca. 2500 Punkten im Passmark Benchmark auf über 1 Million Zeilen pro Minute bzw. 20.000 Zeilen pro Sekunde. Mit vielen Kreuzbeziehungen und Units unterhalb von implementation reduziert sich das aber teilweise drastisch auf unter 5.000. Von daher hängt die Geschwindigkeit stark vom Quelltext ab.

Extrem bremsen tun auch der Windows Defender (nur mit Aktivierung des Defenders halbiert sich hier die Geschwindigkeit fast), aber auch z.B. AVG oder Kaspersky haben ziemlich gebremst. Mit Norton sinkt die Leistung zwar auch, aber nicht so extrem.

[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

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

[arnof]

Viel mehr geht aktuell nicht ... Ohne Fixpack mehrere Minuten Wartezeiten in der IDE mit Fixpack ist die IDE Benutzbar (große Projekte und keine Spassprojekte); Deshalb ist 10.4 aktuell nicht richtig nutzbar für mich ...

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