Kompilieren dauert IMMER lange

[Der schöne Günther]

Ich verwende momentan Delphi 10 Seattle mit Update 1.

Angenommen ich ändere im Quellcode eine einzige Konstante ab. Drücke ich Strg+[F9] habe ich 9-13 Sekunden lang eine Sanduhr. Im Compiler-Fenster zählt er nur ein paar hundert Zeilen hoch, mehr muss er auch nicht. Das Projekt ist auch nicht groß: Die .exe ist ca 25 MB, ca. 120.000 Programmzeilen.

Was dauert hier so lange? Es macht mich wahnsinnig. Jedes mal. Ein komplettes Neu-Builden dauert ca 1-2 Sekunden mehr.


"Bereinigen" hilft nicht. IDE Fix Pack ist installiert. Rechnerleistung ist sicher nicht der Flaschenhals.

[SneakyBagels]

Zitat:

Das Projekt ist auch nicht groß: Die .exe ist ca 25 MB, ca. 120.000 Programmzeilen.

25MB und 120.000 Zeilen empfine ich als groß.
Kannst du ausschließen, dass es am Code liegt? Hast du eventuell ein vergleichbares Projekt, welches du zum Test kompilieren könntest

[TiGü]

Ist das auch so bei Kollegen, die das Projekt builden?

[Bbommel]

Für mich klingt diese Denkpausen-Sanduhr eher danach, als hättest du irgendwo ein Netzlaufwerk eingebunden, das wahrscheinlich nicht erreichbar ist oder ähnliches. Hat sich irgendwo in den Projekt-Optionen im Pfad für die Bibliotheken oder die Ausgabe vielleicht etwas in die Richtung eingeschlichen?

[Der schöne Günther]

Das ist eine gute Idee! Netzlaufwerke habe ich keine. Dafür aber mittels

Delphi-Quellcode:

subst

-Befehl "künstlich erzeugte" Laufwerke. Das wird aber kein Problem sein, denke ich.

Hier mal ein paar Tests

Projekt A

• 70.000 Zeilen
• Build: 5 Sek. (Seattle), 5 Sek. (XE7)
• Eine Zeile ändern: 2-3 Sek. (Seattle), 1.5 Sek. (XE7)

Projekt B

• 120.000 Zeilen
• Build: 13-14 Sek. (Seattle)
• Eine Zeile ändern: 8-10 Sek. (Seattle)

Projekt C

• 65.000 Zeilen
• Build: 11 Sek. (Seattle), 7 Sek. (XE7)
• Eine Zeile ändern: 4-5 Sek. (Seattle), 5-6 Sek. (XE7)

A und C sind akzeptabel, B macht echt keinen Spaß mehr. Auf XE7 kann ich es nicht ausprobieren denn da kompiliert es nicht mehr.

Andere arbeiten momentan hauptsächlich an Projekt A und da scheinen die Zeiten ebenfalls so zu sein wie bei mir.

[bra]

Naja, was so lange dauert ist das Erzeugen der Exe. Ich habe das mal mit unserem Projekt unter Tokyo getestet (~250.000 Zeilen, in VMWare alles auf SSD):

Erstes Build nach Neustart: 35sek, danach jeweils 10sek
Kompile ohne irgendwas zu ändern: 6-9sek

Wenn man dann eine App für Android erzeugt, kann man die Zeiten gut verzehnfachen (bei deutlich weniger Code).

[Der schöne Günther]

Das ist klar, wenn man den LLVM-Compiler anwirft wird es Zeit für die Mittagspause oder einen kleinen Betriebsausflug. 8-)


Ich bin nur ehrlich gesagt ziemlich baff wie der PC für nichts mehrere Sekunden brauchen kann. Kann ich nicht herausfinden wo die Zeit hingeht?

Anhang 47474
(Quelle: xkcd.com)

[Rollo62]

Ein Trick von Grijjy bei Mobile war auf die CompilerPotion auf limited Debug information zu schalten.

Rollo

[Der schöne Günther]

Das hat mich auf die richtige Spur gebracht, vielen Dank!

Zitat:

You would expect that Release builds take longer to compile than Debug builds, since it has to perform a bunch of code optimization phases. But the opposite is true.

Das Abschalten der Map-Datei (detailliert) und Einlinken von Debug-Optionen frisst jedes mal die ganze Zeit. Die brauche ich zum Debuggen doch eh nicht, richtig?

Ein Kompilieren ohne jegliche Änderungen dauert jetzt "nur" noch viereinhalb Sekunden.

[Mavarik]

hmm...

FMX Build mit 10.1 103.000 LOC ~2,5 Sekunden Linkzeit nicht messbar... (Windows)

[jaenicke]

Deshalb haben wir gemeinsame Units in Packages (nur zum Kompilieren) ausgelagert, die dann nicht in die Projekte eingebunden sind. Das reduziert die Kompilierzeit extrem.
Der Linker wird dadurch natürlich nicht schneller.

Was ist das denn für eine CPU?

[SneakyBagels]

Zitat:

Zitat von Der schöne Günther (Beitrag 1373823)

Das ist eine gute Idee! Netzlaufwerke habe ich keine. Dafür aber mittels

Delphi-Quellcode:

subst

-Befehl "künstlich erzeugte" Laufwerke. Das wird aber kein Problem sein, denke ich.

Hier mal ein paar Tests

Projekt A

• 70.000 Zeilen
• Build: 5 Sek. (Seattle), 5 Sek. (XE7)
• Eine Zeile ändern: 2-3 Sek. (Seattle), 1.5 Sek. (XE7)

Projekt B

• 120.000 Zeilen
• Build: 13-14 Sek. (Seattle)
• Eine Zeile ändern: 8-10 Sek. (Seattle)

Projekt C

• 65.000 Zeilen
• Build: 11 Sek. (Seattle), 7 Sek. (XE7)
• Eine Zeile ändern: 4-5 Sek. (Seattle), 5-6 Sek. (XE7)

A und C sind akzeptabel, B macht echt keinen Spaß mehr. Auf XE7 kann ich es nicht ausprobieren denn da kompiliert es nicht mehr.

Andere arbeiten momentan hauptsächlich an Projekt A und da scheinen die Zeiten ebenfalls so zu sein wie bei mir.

C aber ist ja genau so langsam wie B wenn man sich die Anzahl der Codezeilen ansieht.
Das Problem scheint also in B und C zu sein. A ist scheinbar nicht betroffen.

[Mavarik]

Zitat:

Zitat von jaenicke (Beitrag 1373846)

Was ist das denn für eine CPU?

Ging die Frage an mich?

VMWare und so, siehe hier...

[Der schöne Günther]

In meinem Fall ist es ein schon etwas älterer Intel Corei5 mit 4x3.50 GHz. Bei einem frischen Build von Null an futtert er, egal welches Projekt, abertausende Quellcode-Zeilen einer Sekunde runter, das ist völlig in Ordnung.

Und wie gesagt: Ja, Project B und C hatten detaillierte Map-Dateien, Debug-Optionen und alles aufgedreht. Projekt A nicht. Das war der Unterschied.

Für eine Release-Fassung (Exception-Logging) braucht man das, aber für die Debug-Fassung an meinem Schreibtisch natürlich nicht :-)

Ganz zufrieden bin ich natürlich immer noch nicht (vier Sekunden für nichts), aber es ist nicht mehr schlimm. ;-)


Mit Delphi-Packages (diese .bpl-Dinger?) kennt sich hier kein Mensch aus, da fange ich lieber nichts mit an.

[SneakyBagels]

Zitat:

In meinem Fall ist es ein schon etwas älterer Intel Corei5 mit 4x3.50 GHz.

Ich habe einen i5 mit 4x3,3GHz und ein Projekt mit 120.000 Codezeilen. Bereinigen und dann erzeugen dauert hier 5 Sekunden. Eine Zeile ändern und erneut erzeugen 2 Sekunden.

[Rollo62]

Ich glaube der Speicher ist fast wichtiger ...

Rollo

[MEissing]

Das wichtigste: SSD....

(Die IDE ist ja (noch) 32 bittig, so daß hier bei 3 oder 4 GByte RAM sowieso (für den Prozess BDS.EXE) dicht gemacht wird. 8 GB RAM sollte jeder Entwicklerrechner ja haben?!??!)

[Stevie]

Es gibt aktuell in der kompletten Chain mehrere potenzielle Flaschenhälse:

Zum einen sind das nicht voll qualifizierte Units im uses, dann wird einfach stumpf jeder im Projekt angegebene Unit scope name an die gesuchte unit gepappt und in jedem suchpfad geschaut obs die gibt (siehe https://quality.embarcadero.com/browse/RSP-18130).

Und dann noch aufgeblähte dcus die den Linker unter Stress setzen können (was genau da passiert ist noch nicht genau verifiziert - siehe https://quality.embarcadero.com/browse/RSP-18080).

[SneakyBagels]

Zitat:

Zum einen sind das nicht voll qualifizierte Units im uses, dann wird einfach stumpf jeder im Projekt angegebene Unit scope name an die gesuchte unit gepappt und in jedem suchpfad geschaut obs die gibt (siehe https://quality.embarcadero.com/browse/RSP-18130).

Frage nebenbei. Gibt es eine bessere Möglichkeit als Suchen&Ersetzen mit CNPack in allen Dateien, um diese alten Units durch die neuen zu ersetzen?

[jaenicke]

Zitat:

Zitat von MEissing (Beitrag 1373877)

Das wichtigste: SSD....

Und auch eine gute. Da gibt es himmelweite Unterschiede.

Plus eine CPU, die im Benchmark mindestens bei 5000 liegt. Hier eine Liste:
http://www.cpubenchmark.net/cpu_list.php
Wir haben gerade aufgerüstet... so bei 9000 fängt es an Spaß zu machen.

[SneakyBagels]

Zitat:

Plus eine CPU, die im Benchmark mindestens bei 5000 liegt. Hier eine Liste:
http://www.cpubenchmark.net/cpu_list.php

Ich habe einen PC mit Intel Pentium G3258 bei 2x 3,5GHz und eine Billig-SSD von SanDisk. Funktioniert alles bestens. 120.000 Zeilen werden in 3 Sekunden kompiliert (Bereinigen, dann Erzeugen).

Zitat:

Wir haben gerade aufgerüstet... so bei 9000 fängt es an Spaß zu machen.

Nicht jeder hat das Kapital einer Firma :lol:

[mensch72]

Kapital einer Firma besteht aus ZWEI teilen!
1. ManPower, also die Mitarbeiter... wenn die billig genug sind, reichen auch lahme PCs wenn es die dafür nötigen Arbeitszeitkosten ermöglichen
2. Arbeitsmittel, also Investionen in möglichst viele und effektive Hilfsmittel zur Einsparung von Arbeitszeit

Beispiel "Maler"... also einer der mal fix eine Wand weiß machen soll...
- der Heimwerker nimmt günstige Wandfarbe, streicht 2x und klebt weils etwas spritzt vorher alles gut ab
- der Handwerker rollt nur 1x mit 3x so teurer Wandfarbe über die Fläche und da spritzt garnix
Was ist nun billiger? Wenn dem Heimwerker seine "Zeit" egal ist, dann sind seine Materialkosten billiger... weil der Handwerker aber einen sehr hohen Stundensatz hat, rechnet sich bei dem die teure Farbe als Arbeitsmittel.

=> bei EntwicklungsPCs kann man statiönär am Arbeitsplatz schon (ein)mal was schnelles verwenden, muss ja nicht "Marke" sein. Mobile als Notebook sieht es da ganz anders aus... hier zählt "Wert", also Nutzwert plus Image! Es muss ja kein MacBooKPro sein, aber ein IBM,DELL,HP wirken besser wie ein Medion. Daher hat bei uns der Vertrieb/Support oft teurere Geräte wie wir in der Entwicklung;)

[himitsu]

Zitat:

Zitat von jaenicke (Beitrag 1374253)

Zitat:

Zitat von MEissing (Beitrag 1373877)

Das wichtigste: SSD....

Und auch eine gute. Da gibt es himmelweite Unterschiede.

Jupp, oft schauen viele nur auf die schön große Transferrate auf der Vorderseite der Verpackung.

Problem beim Kompilieren ist aber nicht nur die Leserate, sondern auch die Schreibrate und Jene kann plötzlich relativ klein ausfallen.



Firmenkapital...
Bei uns dauert das Kompilieren des gesamten Projekts mehrere Minuten (auf einer SSD)
und da Delphi beim Kompilieren unserer Designtimepackages gern mal verreckt, bleubt dann nur noch das durchlaufen im Finalbuilder, samt Beenden und Neustart der IDE.

Das dann noch mehrmals (oft) pro Tag ... da fallen die Unterschiede von 3 Minuten (langsame) SSD gegen 10 Minuten auf der HDD schon auf.
(SSD war mal schneller, aber wird aus noch unerfindlichen Gründen immer langsamer)


Aber ja, beim Schlepptop geh ich auch bissl teurer, aber privat möchte ich dann auch was, dass jetzt gut und auch noch paar Jahre ausreichend ist.
Ich bin auch nicht der, welcher jedes Jahr ein neues iPhone braucht.

[jaenicke]

Zitat:

Zitat von SneakyBagels (Beitrag 1374259)

Nicht jeder hat das Kapital einer Firma :lol:

Ich glaube du überschätzt die Kosten für die genannten Teile.
CPU 200 Euro, 500er SSD 230 Euro, andere zahlen das privat für eine Grafikkarte.

Zitat:

Zitat von himitsu (Beitrag 1374266)

Problem beim Kompilieren ist aber nicht nur die Leserate, sondern auch die Schreibrate und Jene kann plötzlich relativ klein ausfallen.

Selbst die Schreibrate ist noch nicht einmal entscheidend. Die IOPS sind der absolut wichtigste Faktor beim Kompilieren. Denn es sind extrem viele extrem kleine Dateien betroffen.

Es hilft überhaupt nichts, wenn die SSD 500 MB/s lesen und schreiben kann, aber nur eine IOPS von z.B. 50.000 hat. Leider ist so etwas bei vielen günstigen aber der Fall.

[himitsu]

Aber auch da sind die Write IOPS geringer als die Read IOPS und bei "güntigeren" Platten sieht es manchmal ganz schlimm aus.

[Frickler]

Zitat:

Zitat von jaenicke (Beitrag 1374253)

Zitat:

Zitat von MEissing (Beitrag 1373877)

Das wichtigste: SSD....

Und auch eine gute. Da gibt es himmelweite Unterschiede.

Plus eine CPU, die im Benchmark mindestens bei 5000 liegt. Hier eine Liste:
http://www.cpubenchmark.net/cpu_list.php
Wir haben gerade aufgerüstet... so bei 9000 fängt es an Spaß zu machen.

Das ist ein Multithreading Benchmark. Nutzt denn der Compiler mehrere CPU-Kerne? Wenn nicht, wäre diese Tabelle ausschlaggebend.

[himitsu]

Ich glaub kaum, das es viele Compiler/Linker gibt, welche wirklich multithreaded arbeiten.

Die fangen in der Projektdatei an und arbeiten sich dann nach und nach durch das Projekt durch.
Delphi als Single-Pass Compiler (One-Pass) nur einmal von Vorne bis hinten. (Compiler/Optimierer > Linker)
Und C als Multi-Pass Compiler läuft Mehrmals drüber (1-2 Mal über den Code und dann noch paar Mal über das letzte Ergebnis des Compilers/Optimiers)

Aus jemen Grund kann man in C teilweise schon auf Dinge zugreifen, welche erst später kommen, während man in Delphi nur auf vorherrige Deklarationen Zugriff hat.

Aber letztendlich wird dennoch alles nacheinander gemacht, da jeder Prozess das vorhergehende Ergebnis braucht ....... Allerdings könnte (vorallem beim Pascal) jeder Schritt schon parallel (leicht versetzt) ablaufen, da die bereits fertig bearbeiteten Teile meistens nicht nochmal verarbeitet/verändert werden und somit feststehen.



Tipp: Kompiliere eine größeres Projekt und du wirst erkennen, dass praktisch nur ein Kern verwendet wird.
Im FinalBuilder nutzen wir das aus, indem mehrere nicht untereinander abhängige Projekte (EXE/DLL/BPL) gleichzeitig kompiliert werden. Passend zur CPU-Größe und bei langsamen HDDs nicht zu viele, da die Festplattenzugriffe sich gegenseitig extrem ausbremsen.

[jaenicke]

Zitat:

Zitat von Frickler (Beitrag 1374276)

Das ist ein Multithreading Benchmark. Nutzt denn der Compiler mehrere CPU-Kerne? Wenn nicht, wäre diese Tabelle ausschlaggebend.

Da hast du natürlich Recht, ich benutze nur meistens die Seite mit Sucheingabe. Wir sind aktuell beim Intel Core i5-7600K, der ist in beiden Listen gut dabei und verhältnismäßig günstig.

[Der schöne Günther]

Ist das in späteren Delphi-Versionen (nach 10 Seattle) besser oder noch schlimmer geworden?

Kann ich noch irgendetwas tun um herauszufinden weshalb er bei manchen Projekten so lange für ein "Compilieren" brauch obwohl nichts geändert wurde?

[Delphi.Narium]

Eventuell dasda befolgen / nachahmen? AW: Delphi, sehr umfangreiche Projekt-Ordner-Struktur, wie Dateien finden

[hoika]

Hallo,

Zitat:

Kann ich noch irgendetwas tun um herauszufinden weshalb er bei manchen Projekten so lange für ein "Compilieren" brauch obwohl nichts geändert wurde?

Machst Du ein Compile oder Build?
Im Task-Manager unter Leistung die Plattenaktivität prüfen.
Im Prozessmonitor mal nachsehen, ob Suchpfade im Projekt sind, die es nicht mehr gibt oder die temporär nicht verfügbar sind (Netzwerk-Laufwerk).

[dummzeuch]

Meine Erfahrung mit SSDs (Intel bzw. jetzt Samsung 850 EVO 1TB) war, dass der Unterschied beim Compilieren im Vergleich zu einer Festplatte (Samsung Barracuda 1 oder 2 TB) marginal war.

Compilezeiten von einer Minute und mehr kenne ich gar nicht. Das größte unserer Projekte braucht gerade mal 20 Sekunden für einen kompletten rebuild incl. aller 3rd-Party Sourcen. Insgesamt sind das knapp 2 Mio. Zeilen. Darin enthalten sind auch noch Aufrufe von externen Tools in pre- und postbuild events.

Das mag daran liegen, dass unsere Projekte im Vergleich zu anderen doch kleiner sind, als ich immer annahm. Oder es liegt daran, dass wir größtenteils immernoch Delphi 2007 einsetzen.

Aufgrund dieser Erfahung verwende ich die SSD als Systemplatte, die Sourcen liegen aber auf einer Datenplatte. D.h. die Zugriffe auf die RTL/VCL sollten von der SSD profitieren, die auf unsere und die 3rd-Party Sourcen nicht.

Nur testweise habe ich das o.g. Projekt gerade mal in einer VM compilieren lassen, bei der durch andere Prozesse bereits die beiden virtuellen CPU-Kerne zu 100% ausgelastet waren. Compilezeit 1 Minute 20 Sekunden. Die VM liegt auf einem gut ausgestatteten XenServer, allerdings ist auch dort nur die Bootplatte eine SSD, der Rest liegt auf Festplatten im RAID5.
Wenn die VM sonst nichts zu tun hat, komme ich auf die gleichen Compilezeiten wie auf meinem Arbeitsrechner: ca. 20 Sekunden.
Die VM ist eine virtualisierte Kopie meines Arbeitsrechners, d.h. auch sie hat zwei getrennte (virtuelle) Platten für Betriebssystem und Daten (Sourcen).

Theorie: Vielleicht ist es ja auch von Vorteil, wenn die Sourcen / DCUs auf zwei verschiedene Datenträger verteilt sind?


twm

[hoika]

Hallo,
also ich merke die Benutzung einer SSD sehr.
Mindestens Faktor 4-5 ist es schneller.
Und wir haben auch große Projekte (> 2Mio. Zeilen).

[sakura]

Mal eine einfach Frage: hast Du das IDE FixPack von Andreas Hausladen installiert?

...:cat:...

[Der schöne Günther]

Es geht nur um das Drücken von Strg+F9 ("Kompilieren") für ein bereits kompiliertes Projekt. Er braucht hierfür (obwohl sich nichts geändert hat) locker 5 Sekunden. Das finde ich nicht akzeptabel.

• Virenscanner an/aus kein Einfluss
• RAD Studio Installation auf SSD 1, Delphi-Projekt auf SSD 2
• Ja, IDE Fix pack ist installiert

Ich habe mit dem Process Monitor mal geschaut.

Hier wie der zeitliche Ablauf. Links der Zeitpunkt nach wieviel Sekunden, rechts was er bis dahin gemacht hat...

1,9 s	DCU und PAS-Dateien vergleiche, DCUs einlesen
2,65 s	Exe-Datei schreiben
3,0 s	DFM und RES-Dateien einlesen
4,3 s	Exe-Datei schreiben
7,3 s	.map und .rsm-Datei schreiben

Ich sehe zwei Probleme:

1. Ich weiß nicht ob das im Process Monitor falsch ankommt, aber es sieht so aus als würde er die .exe-Datei immer in kleinen Blöcken geschrieben. Ein WriteFile(..) mit 200 Bytes, dann eins mit 500, … Sowas ist der Performance sicher auch nicht zuträglich
2. Er schreibt .map und .rsm-Dateien (wird im Dialog als "Linken..." angezeigt) obwohl ich das alles abgestellt habe. Scheint ihn nicht zu kümmern...

[DieDolly]

Zitat:

Er schreibt .map und .rsm-Dateien (wird im Dialog als "Linken..." angezeigt) obwohl ich das alles abgestellt habe. Scheint ihn nicht zu kümmern...

Kompilierst du in 64 bit? Da wird bei mir auch eine Map-Datei erstellt, obwohl deaktiviert.

[Stevie]

Nutzt du Generics, Spring4D? Sofern möglich, lass mir mal die map Datei zukommen, ich schau da mal rein - siehe auch https://bitbucket.org/sglienke/spring4d/issues/310

[Der schöne Günther]

Nein, das war 32 Bit.

Zitat:

Zitat von Stevie (Beitrag 1428388)

Nutzt du Generics, Spring4D?

Ja, in rauen Mengen 😎

Die map-Datei schaffe ich heute wahrscheinlich nicht mehr, aber ich versuche es demnächst, danke ❤