D12 - 1' 20" Kompilierzeit für 10 Zeilen Code und 5 Komponenten??

[jik]

Im Forum habe ich keine Posts gefunden, die das Problem so richtig treffen.

Ich habe Delphi 12 in einer VMWare-Session installiert, die auf einer SSD läuft, Prozessor Intel(R) Core(TM) i7-9700K CPU 3.60GHz, Speicher in VMWare-Instanz 6 GB.
Worum es geht, steht eh im Titel. Das Seltsame dabei ist, dass nahezu die gesamte Wartezeit für etwas Geheimnisvolles VOR dem Kompilieren draufzugehen scheint. Man kann das schön im Taskmanager verfolgen: Da tut sich nur zu Beginn zwei Sekunden was bei der CPU, dann ist Stille, bis ganz am Schluss die paar Codezeilen durchrauschen, wo sie noch einmal minimal ackert. Der Speicher stehet durchgehend gleichmäßig auf etwa 45% Nutzung.

Edit: Wenn ich übrigens keine Änderung habe, dann startet das Programm nach einer Sekunde.

WTF macht der Mistkerl da Geheimes ...?

[Uwe Raabe]

Hier dauert das compilieren von gut 1 Mio. Zeilen in 740 Units auf einem ähnlichen System ca. 10 Sekunden.

[t2000]

Hast du dein vmWare richtig eingerichtet?
Ich habe fast das gleiche System, nur mit dem i7-8700K Prozessor. Aber meine VM hat 32 GB und 8 Kerne (logische Prozessoren). Falls du nur 1 Kern zugeornet hast, könnte das der Grund sein.

Aber auch bei mir geht alles rasend schnell.

[t2000]

https://www.delphipraxis.net/attachm...1&d=1705754252

[himitsu]

@Uwe Das Compilieren mit einer/keiner geänderten Unit, oder wirklich ein kompletter Build? :roll:



In der Ereignisanzeige vom Windows ist nicht zu sehn, dass irgendwas massig Meldungen/Fehlermeldungen raushaut?


Nja, erstmal der Taskmanager und der Ressourcenmonitor

Delphi-Quellcode:

%windir%\system32\perfmon.exe /res

könnten einen Blick wert sein, um grob zu sehn, ob man irgendwas bremsendes sieht.
Es gibt ja nicht nur die CPU, sondern auch RAM und den Datenträger.
Beim RAM vor allem die Ein-/Auslagerung (PageFaults bei den Details im Taskmanager)
Beim Datenträger nicht nur die reine Menge der Daten, sondern auch die Anzahl/GrößeKleine der I/Os.

Und da es eine VM ist, das Ganze auch nochmal auf Seiten des Hosts.


Für mehr dann noch der bekannte Prozessmonitor

Delphi-Quellcode:

https://learn.microsoft.com/de-de/sysinternals/downloads/procmon

(wobei man hier mehr nur erkennt, ob z.B. zu viele "fehlerhafte" Zugriffe bremsen)
oder sogar das Log des Windows selbst (ihr wollt nicht wissen, was es alles loggt, aber zum Glück normal nicht alles auswertet/speichert)

Also bissl ausführlicher über den Windows Performance Recorder

Delphi-Quellcode:

C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\wpr.exe

bzw.

Delphi-Quellcode:

wprui.exe

und Viewer/Analyzer

Delphi-Quellcode:

wpa.exe

Falls es nicht teilweise durch Delphi bereits installiert ist -> bestimmt im https://developer.microsoft.com/en-u...s/windows-sdk/
Das Verzeichnis ist knapp 180 MB winzig, ohne Redistributables, legacy und gpuview, und kann einzeln kopiert werden.
(k.A. wozu, da das WMI/WindowsHighPerformanceLog im Windows schon seit ewig installiert ist und ich es mit einer nichtmal 1MB-Delphi-App auch ansprechen kann)



Falls du selbst damit nicht klar kommst, dann das WPRUI starten, mehr Optionen und
bei Recource-Analysis noch bissl was aktivieren
Scenario auf General lassen
Mode in Memory oder besser File (Einiges kann eh nur Live oder in eine Datei geloggt werden)
und starten
Speichern und das Log jemandem zur Analyse geben.

Beachte, dass diese Logs sehr groß werden können. (alles genannte angehakt, auch schonmal über 1 GB die Minute, da ohne Filter)

ACHTUNG: nach dem Start unbedingt Speichern+Stoppen oder Stoppen (Cancel) und nicht einfach das Programm schließen.
An viele Logs kann sich nur ein Recorder anhängen und wenn das im Hintergrund weiterläuft *, war's das. (Du kannst dann nur hoffen dass kein Autostart für den Logger angegeben wurde somit ein Neustart des Windows hilft)
*) Dieses LogTool ist kein LiveLogger, sondern sagt Windows nur was wohin geloggt werden soll.




Wir haben auch grade bei zwei Kunden mit je einem Rechner ein Problem, dass dort unser Programm langsam läuft.
Bei einem ist es ein defekter Festplattenkontroller (laut Logs in der Ereignisanzeige) und der Andere ... weiß noch nicht.

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1532310)

@Uwe Das Compilieren mit einer/keiner geänderten Unit, oder wirklich ein kompletter Build? :roll:

Für 1 Million Zeilen sind 10 Sekunden doch absolut realistisch, vorausgesetzt es gibt keine Kreuzbeziehungen zwischen Units. Wenn das Kompilieren lange dauert, sind Kreuzbeziehungen die häufigste Ursache. Diese verlangsamen das Kompilieren exponentiell.

[TurboMagic]

Ja, Kreuzbeziehungen bremsen aus. Aber bei 10 Zeilen Code? ;-)

[jaenicke]

Zitat:

Zitat von TurboMagic (Beitrag 1532325)

Ja, Kreuzbeziehungen bremsen aus. Aber bei 10 Zeilen Code? ;-)

Ich meinte das rein auf Uwes Angabe und himitsus Nachfrage bezogen, nicht in Bezug auf die ursprüngliche Frage.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1532310)

@Uwe Das Compilieren mit einer/keiner geänderten Unit, oder wirklich ein kompletter Build? :roll:

Komplettes Build - aber eben auch keine zyklischen Abhängigkeiten (obwohl das in dem beschriebenen Fall nicht die Ursache sein dürfte).

Der Virenscanner könnte auch mitspielen.

[jaenicke]

Oder sind vielleicht irgendwelche Addons aktiv wie Eurekalog, die sich in den Buildprozess einklinken? Oder Buildevents? Das sieht man dann oft im Ausgabefenster.

[BerndS]

Sind da vielleicht ungültige Netzwerkpfade im Bibliothekspfad drin?

[himitsu]

Zitat:

Zitat von jaenicke (Beitrag 1532323)

Für 1 Million Zeilen sind 10 Sekunden doch absolut realistisch,

OK, ein paar Kreuze, aber ich wundere mich auch bissl

Gut, wir arbeiten mit knapp 80 Packages und DLLs.
Die paar dutzenden FremdPackages kompilieren auch recht schnell. (und zusätzlich auch noch multithreaded, paar verschiedene Komponenten gleichzeitig)
aber z.B. auch DevExpress ist echt langsam, für seine paar 100 Packages. (egal ob deren Setup oder wenn ich es selbst kompiliere)

Aber auch unsere Projekte (ich glaub waren auch mehrere 100.000 Zeilen) da geht es schon langsam (2-3 minütchen, im Finalbuilder und nun D11/D12, mit MSBuild dazwischen, noch einen Hauch länger)
Innerhalb der IDE dauert es länger, weil die unabhängigen DLLs und paar Packages ja nacheinander und nicht parallel, wie im FinalBuilder (bei massig 64 bis 220 GB RAM und bis zu 64 Kernen, geht da schon was)



So Kleinkram, ohne Packages, rauscht aber auch flott durch.

[TurboMagic]

Zitat:

Zitat von jaenicke (Beitrag 1532328)

Zitat:

Zitat von TurboMagic (Beitrag 1532325)

Ja, Kreuzbeziehungen bremsen aus. Aber bei 10 Zeilen Code? ;-)

Ich meinte das rein auf Uwes Angabe und himitsus Nachfrage bezogen, nicht in Bezug auf die ursprüngliche Frage.

Grundsätzlihc klar, ich wollte aber wieder ein bisschen die Kurve zum eigentlichen Thema/Fall einschlagen ;-)
Die Idee mit Eurekalog oder MadExcept: ja, die würden ein wenig Zeit kosten, aber ich denke nicht, dass das
soviel sein sollte.

Bleibt blos alles systematisch abzuklopfen.
Was für ein Virenscanner wird benutzt?

[DieDolly]

Bei mir 600.000 Zeilen Code (eigenes Programm 70.000 Zeilen, der Rest Komponenten) rund 7 bis 9 Sekunden.
Mein Code ist nicht schön aber funktionsfähig, das reicht mir.

Getestet mit Menu > Projekt > Syntaxprüfung

[Sinspin]

Zitat:

Zitat von BerndS (Beitrag 1532332)

Sind da vielleicht ungültige Netzwerkpfade im Bibliothekspfad drin?

Das wäre auch mein Tip.

ProcessMonitor macht das schön sichtbar, da werden die ganzen "folder not found" / "file not found" events aufgelistet.

[jik]

Nur der Ordnung halber der Stand der Dinge:

Zuerst habe ich meine Prozessoren laut Beispiel von T2000 in der VMWare-Session hinaufgesetzt laut Beispiel. Danach ist nicht nur die Session eingefroren, sondern das ganze System gestanden. Dann hatte ich zwei Tage zu tun, um alles wieder in den Griff zu bekommen (war ja eh Wochenende :?) - Taskmanager war tot, Neubooten 20 Minuten usw.

Da ich ohnehin dachte, dass das nicht funktionierende GetIt an mir liegt, habe ich auch gleich die noch neue VM-Session weggeworfen und dachte mir, ich installiere halt Delphi neu und richte es mir wieder so her wie ich schon hatte, denn zu Beginn hatte ja GetIt funktioniert. Ich dachte, die Connection wäre durch meine VM-Session-Verschiebung verlorengegangen. Dann wollte ich Delphi neu installieren und ... GetIt geht nicht. Mittlerweile hatte ich auch den betreffenden Thread hier entdeckt. Nun ja, jetzt kann ich nicht einmal D12 installieren. Ich bin begeistert.

[t2000]

Ich hoffe doch, du hattest min 1 Kern für das Hostsystem gelassen.

Ich habe insg. 12 Kerne und nutze 8 für die Delphi-VM. Ich weiß nicht, was dein Prozessor hat.

[himitsu]

Und nur 1 einziger Kern für den Host?
Wenn der Host mehr als nur für die Verwaltung der VMs da ist, wird er bestimmt gern auch ab und an mal bissl mehr machen wollen.

Wobei 1 Kern nicht unbedingt 1 Kern sein muß.
Laut Taskmanager hat mein i7 16 Kerne, aber eigentlich sind es 4 Performance-Cores mit Hyper-Threading und 8 Efficient-cores ohne.