Kompilieren dauert IMMER lange

[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 von Der schöne Günther:

Das ist eine gute Idee! Netzlaufwerke habe ich keine. Dafür aber mittels 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 von jaenicke:

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 von MEissing:

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.