Compilierzeit zu hoch, was ist falsch?

[ralfschwalbe]

Dann bin ich sprach- und ratlos... Ist der PC standalone, im Netz oder im Netz mit Domäne? Bei Domäne hab ich vor längerer Zeit, trotz Dateien im User-Verzeichnis, auch schon Sorgen beim Zugriff gehabt. Aber nicht do drastisch...

[blackfin]

Vielleicht ein Hinweis?:
Bei mir ist es in Delphi 2009 / 2010 so, dass, falls viele Ausgabe-Hinweise oder -Warnungen in der Ausgabebox des Compilers ausgegeben werden, die Compilierzeit um den Faktor 100-500 höher ist.
Vielleicht diese mal testweise deaktivieren?
Allerdings ist das ja der CMD-Compiler..mhm...ich weiss nicht, ob das darauf auch Einfluss hat...

[ralfschwalbe]

Jo, dass ist mir auch grad noch eingefallen... Zu spät

[sx2008]

Es gibt da bestimmte Compilerwarnungen, die wenn sie aktiviert sind die Kompilierzeit dramatisch erhöhen.
Ich habe bei Tests so Faktor 5 bis 20 gesehen.
Leider kann ich mangels aktueller Delphi-IDE nicht mehr genau sagen welche es waren, aber ich denke diese müssten es sein:

Delphi-Quellcode:

{$WARN SYMBOL_DEPRECATED OFF}
{$WARN SYMBOL_LIBRARY OFF}
{$WARN SYMBOL_PLATFORM OFF}
{$WARN UNIT_LIBRARY OFF}
{$WARN UNIT_PLATFORM OFF}
{$WARN UNIT_DEPRECATED OFF}
{$WARN UNSAFE_TYPE OFF}
{$WARN UNSAFE_CODE OFF}
{$WARN UNSAFE_CAST OFF}

PS: das kommt davon, wenn man die vorherigen Postings nicht liest.
siehe #15 von blackfin

[himitsu]

Das UnsafeCase sollte man lieber anlassen, denn das könnten auch Mal schwerere Problemchen sein,
wie z.B. wie einen AnsiString nach PChar casten zu wollen.

Das Deprecated-Zeugs merkt man spätestens, wenn in einer späteren Delphi-Version dieses endgültig weg ist.
(kann aber nicht schaden das jetzt schon zu wissen und gleich zu beseitigen )

Und der Rest ist eigentlich nut "sinnloses" .Net-Kompatibilitätsgedöhns, was eh kein Schein mehr interessiert,
vorallem seit Delphi .NET sowieso tot ist

@blackfin:
Compilerschalter im Code haben auf alle Compiler eine Wirkung, schießlich interpretiert der Commandozeilencompiler auch den Code.
Nur kann man beim Commandozeilencompiler via Parameter einige die Voreinstellungen ändern, welches beim Inlinecompiler über die Projektoptionen gemacht wird.

[AThurm]

Zitat von blackfin:

Allerdings ist das ja der CMD-Compiler..mhm...ich weiss nicht, ob das darauf auch Einfluss hat...

Nein hat es nicht. Ich habe mal alle Warnungen aus Spass deaktiviert, in der IDE liefs dann statt mit 1000 Sekunden in 600 (was immer noch viel zu hoch ist, im Vergleich zu Delphi 7), aber in DOS blieb es bei den 1000s. Ich versuche jetzt auserhalb der Domaine das Projekt zu compilieren, ansonsten fällt mir nichts mehr ein

[himitsu]

Man könnte mal versuchen über die OpenToolAPI sowas wie AQTime in die IDE einzuschleußen.
Eventuell bekommt man da etwas vom Inlinecompiler mit.

Ansonsten bleibt nur noch eine Anfrage im QC oder direkt an den Support.
Hoffentlich kommt dann keine Antwort ala "Kaufen sie XE, denn dort ist ein Bugfix dafür vorhanden".

[dataspider]

Ich hatte etwas in der Art 2 Mal.
Einmal waren für das Debugger - Ereignisprotokoll alle möglichen Meldungen angehakt.
Ein anderes Mal waren es nicht mehr existierende Pfadangaben (ich meine, es war ein Suchpfad in den Projektoptionen).

Frank

[AThurm]

Zitat von himitsu:

Man könnte mal versuchen über die OpenToolAPI sowas wie AQTime in die IDE einzuschleußen.
Eventuell bekommt man da etwas vom Inlinecompiler mit.

Gute Idee, kann ich mal ausprobieren!

Zitat von dataspider:

Ich hatte etwas in der Art 2 Mal.
Einmal waren für das Debugger - Ereignisprotokoll alle möglichen Meldungen angehakt.
Ein anderes Mal waren es nicht mehr existierende Pfadangaben (ich meine, es war ein Suchpfad in den Projektoptionen).

Frank

Das probiere ich mal aus, danke.
Ist es ein Problem für den Compiler wenn die Suchpfade relativ angegeben sind ? (Sie sind nicht "grau" (Existiert also) unterlegt)
Zum Beispiel: ..\source\

[himitsu]

Zitat von AThurm:

Gute Idee, kann ich mal ausprobieren!

Wir hatten jetzt mal das "Problem", dap die IDE-Exceptions (bei Fehlern in der IDE) urplötzlich über EurekaLog liefen.
Der Grund war einfach, daß in einem DesignTimePackage das EurekaLog mit drin war und es sich somit auch in der IDE einnistete.

Package wäre der einfache Weg und über die OTA kommt man eventuell an mehr Infos ran.

An dieser Stelle würde ich relative Pfade weglassen,
denn sie hängen ja vom aktuellen Arbeitsverzeichnis ab und das kann sich schnell mal ändern.

Du kannst aber Variablen nutzen, so wie das $BDS oder $(BDS), wobei man dort alles aus den Umgebungsvariablen nutzen kann.
$TEMP = $(TEMP) und entspricht quasi einem %TEMP%

$(TEMP) ist dafür, falls weitere Buchstaben/Zahlen direkt folgen
$TEMPXYZ <> $(TEMP)XYZ