Kompilieren dauert IMMER lange

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

[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

[himitsu]

Zitat von jaenicke:

Zitat von MEissing:

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.