10.4 Sydney IDEFixpack kommt da noch was ?

[Borni]

Hallo Zusammen,

die Compilerzeiten bei großen Projekten sind echt überirdisch. Wir warten händeringend auf das fixpack für 10.4. Kommt da noch was ?
Oder müssen wir warten bis embc da was macht ? (Oder habe ich was überlesen oder nicht gesehen? *duck*)

Gruß an Alle

[himitsu]

10.3 ist aktuell das Neuste.
https://www.idefixpack.de/
https://www.idefixpack.de/blog/ide-tools/ide-fix-pack/

Letzte mir bekannte Infos, hier im Forum (siehe jbg)
https://www.delphipraxis.net/204514-...ml#post1466247 (dauert also noch paar Monatchen)
https://www.delphipraxis.net/199928-...ml#post1426832

[Rolf Frei]

Aber Andreas soll doch gratis eine 10.4 Lizenz bekommen, gemäss Matthias Eißing. Da muss er nicht auf die CE warten. Ist das eventuell noch nicht bis zu ihm durchgedrungen? Ist er hier überhaubt noch aktiv?

[TurboMagic]

Hallo,

Andreas Hausladen will m.W. gar keine gratis Lizenz, damit es für nichts verpflichtet ist. EMBT hat außerdem den Quellcode des Fixpacks gekauft und begonnen die Teile davon zu integrieren, die sie für sicher genug erachten.

EMBT ist scheinbar nicht über jeden Trick von Andreas erfreut.

Was passt an Sidney nicht, dass du einen solchen Fixpack brauchst?

Grüße
TurboMagic

[Borni]

Zitat:

Zitat von TurboMagic (Beitrag 1472774)

Was passt an Sidney nicht, dass du einen solchen Fixpack brauchst?

Ganz einfach ein großes Projekt komplett zu erzeugen
unter 10.3.3 mit fixpack ca. 8-9s,
unter 10.4 ohne fixpack ca. 59s, das nervt auf die Dauer !

Gruß Borni

[win568]

Hi

Emba soll nicht über Tricks von Andi erfreut sein, sondern die Fehler ausbessern. Ohne seine Änderungen
läuft bei uns gar nichts mehr (23 Mio Locs). Die Stabilität von 10.4 ist eine Frechheit. Das neue beworbene
Codeinsight funkt überhaupt nicht. Ich verwende daher wieder unsere eigene Implementierung als Experts Erweiterung.
Nicht mal so einfache Geschichten wie Layout speichern funktioniert. Und wir müssen für dutzende Leute
ständig Lizenzen nachkaufen, für ein Produkt das immer schlechter wird.

[himitsu]

Nur 1 Minute? :shock:

Ich brauch im XE selbst mit IdeFixPack schon fast 5 Minuten (nur unsere Projekte ohne Fremdbibliotheken > etwa 70 EXE/BPL/DLL und ne Mio Codezeilen).
Im FinalBuilder bin ich, Dank Multithread auf 32/63 Kernen und 62 GB, runter auf 1,5 Minuten inkl. aller Fremdkomponenten (von anfänglich knapp 6-10 Minuten auf den alten/kleinen Rechnern)

Wie lange es im 10.4 dauert, werd ich hoffentlich in paar Wochen rausbekommen, aber der letzte Test im 10.3 (der erste Vollständige) lag bei unter 3 oder 5 Minuten ohne IdeFixPack, glaub ich.


Codeinsight hatte ich auf Classic umgestellt ... da geht einiges Neues nicht, aber es lief wieder besser, auch wenn nicht annähernd so gut, wie vorher.

[TurboMagic]

Zitat:

Zitat von win568 (Beitrag 1472784)

Hi

Emba soll nicht über Tricks von Andi erfreut sein, sondern die Fehler ausbessern. Ohne seine Änderungen
läuft bei uns gar nichts mehr (23 Mio Locs). Die Stabilität von 10.4 ist eine Frechheit. Das neue beworbene
Codeinsight funkt überhaupt nicht. Ich verwende daher wieder unsere eigene Implementierung als Experts Erweiterung.
Nicht mal so einfache Geschichten wie Layout speichern funktioniert. Und wir müssen für dutzende Leute
ständig Lizenzen nachkaufen, für ein Produkt das immer schlechter wird.

Einen gewissen Frust kann ich verstenen, aber es wird ja inzwischen wieder aktiver an der IDE gearbeitet.
Jetzt ist 10.4.1 raus und da sind diverse Fixes für den LSP drin. Damit ist zwar noch nicht alles gut,
speziell aber bei größeren Projekten verhält er sich glaube ich ein recht gutes Stück besser!
Aber eine Aussage "funkt überhaupt nicht" ist so grobschlächtig nichtssagend, dass ich damit nichts anfangen kann.
Was genau geht nicht? Kommt keine Code Competion? Findet er Sachen nicht? Blockiert es die CPU...?

Und zum Fixpack: es geht hier nicht um "über Tricks erfreuen" sondern darum abzuschätzen welche der Dinge
die er mittels Fixpack gelöst hat sicher genug sind um diese zu übernehmen, was ja schon begonnen hat,
und welche man besser sein lässt, weil die doch zu viel Risiko beinhalten bei irgendjemand doch schief zu gehen.
Also nicht so einfach...

Ich hoffe auch, dass irgendwelche GetIt Probleme mit der neuen Patch Installationsmöglichkeit behoben sind, so
dass zeitnah weitere Dinge mittels Patch verbessert werden können!

[Borni]

Hallo zusammen,

die Compilerzeiten sind auch unter 10.4.1 nicht besser geworden. Oder gibt es noch einen anderen Trick ? (Compiler Speed Pack, IDE Package und Palette Cache)

Gruß Borni

[himitsu]

Multithreated im Hintergrund den Comandozeilen-Compiler ansteuern.

[Rollo62]

Zitat:

Zitat von Borni (Beitrag 1472912)

Hallo zusammen,

die Compilerzeiten sind auch unter 10.4.1 nicht besser geworden. Oder gibt es noch einen anderen Trick ? (Compiler Speed Pack, IDE Package und Palette Cache)

Gruß Borni

Wie sieht es mit zyklischen Unit-Referenzen aus ?
Die bewirken meines Wissens nach erhebliche Probleme, mit Speicher, Performance, Abstürzen, etc.
Wenn das noch nicht obtimiert ist würde ich mal nachschauen was man auseinanderrupfen kann.
Uwe Raabe's MMX Tool ist da eine große Hilfe.

[OlliWW]

Warten auch schon sehsüchtig auf das FixPack 10.4.

[himitsu]

Kenn viele, die haben USES fast nur in der Implementation.

Ich selber mache möglichst alles nur ins Interface (ist dann auch schön übersichtlich weit oben, die Liste)
und unten kommt nur das rein, was ohne zirkuläre Referenzen nicht geht (oder wo ich grad keine Zeit/Lust hab das anders zu machen).

Und schon hat man mit diesem Problem keine Probleme.

[haentschman]

Zitat:

Ich selber mache möglichst alles nur ins Interface

...ich stimme dir ja nur ungern zu. :stupid: :zwinker:

[freimatz]

Bitte nicht schon wieder diese Diskussion - Danke.

[Daniel]

Sorry - aber da wirst Du einfach weiterklicken müssen. Niemand zwingt Dich, dieses Thema zu lesen - aber Ihr könnt Euch nicht gegenseitig das Wort verbieten.

[Stevie]

Zitat:

Zitat von Daniel (Beitrag 1474118)

Sorry - aber da wirst Du einfach weiterklicken müssen. Niemand zwingt Dich, dieses Thema zu lesen - aber Ihr könnt Euch nicht gegenseitig das Wort verbieten.

Ich glaube, Freimatz meinte die "in welches uses pack ich meine unit" Diskussion, das Thema dieses Threads ist ja IDEFixPack.

[Daniel]

Huch - danke für den Hinweis. In diesem Fall: Sorry.

[freimatz]

Ja, Danke :-D

[Der Bastler]

Wir hoffen auch auf die Compilerbeschleunigung. Das ist für uns das k.o.-Kriterium für den Kauf neuer Delphi-Versionen.
Wir haben derzeit knapp 3 Mio. selbst geschriebener Code-Zeilen und noch einige Imports.
Im RIO mit IDEFixPack sind wir im Optimalfall bei reichlich 6min. Sydney braucht ca. 40 min. (Ist damit aber schneller als RIO ohne IDEFixPack)

Ein wichtiger Trick für das Optimum der Compilerzeiten liegt in der richtigen Reihenfolge der Units im USES. Wir haben hier ewig probiert und optimiert und haben über 30 Minuten rausgeholt.
Wir haben extra ein Tool geschrieben, dass uns die USES sortiert. Beim programmieren landen Neue i.d.R. nicht an der optimalen Stelle.
Evt. hilft Euch das weiter...

Viele Grüße, Lars

[woodie]

Zitat:

Zitat von Der Bastler (Beitrag 1474578)

Wir haben extra ein Tool geschrieben, dass uns die USES sortiert. Beim programmieren landen Neue i.d.R. nicht an der optimalen Stelle.

Was ist die optimale Reihenfolge für den Compiler? Wie findet eurer Tool das automatisch raus?

[dummzeuch]

Zitat:

Zitat von woodie (Beitrag 1474584)

Zitat:

Zitat von Der Bastler (Beitrag 1474578)

Wir haben extra ein Tool geschrieben, dass uns die USES sortiert. Beim programmieren landen Neue i.d.R. nicht an der optimalen Stelle.

Was ist die optimale Reihenfolge für den Compiler? Wie findet eurer Tool das automatisch raus?

:thumb:

Genau dies würde mich auch brennend interessieren.

[OlliWW]

Wahrscheinlich entscheidet das Tool nur ob es in der Implementatation oder im Interface landet. Sowas können aber meines Erachtens nach auch viele andere Tools bereits.

[freimatz]

Zitat:

Zitat von Der Bastler (Beitrag 1474578)

Ein wichtiger Trick für das Optimum der Compilerzeiten liegt in der richtigen Reihenfolge der Units im USES. Wir haben hier ewig probiert und optimiert und haben über 30 Minuten rausgeholt.
...
Evt. hilft Euch das weiter...

Viele Grüße, Lars

Danke. Noch mehr würde es helfen wenn Du uns verrätst, was denn die richtige Reihenfolge ist. :wink:

[himitsu]

Darum auch meine Empfehlung möglichst nur das USES im Interface zu benutzen.

Dort steht dir Reihenfolge fest, also immer in der Reihenfolge, wie es im Code steht.
* erste Unit
* dann das was in dieser Unit steht
* dann zweite Unit (falls nicht bereits in untergeordneten Units geladen)
* usw.

Das was im USES der Implementation steht, das kann der Compiler in beliebiger Reihenfolge einbinden.

Auch werden UNITs der Implementation eventuell erst nach dem Code der Initialization geladen und bereits vor der Finalization entladen,
während die UNITs im Interface immer vor Initialization geladen und erst nach Finalization entladen werden, womit deren Funktionen dort (sicher) nutzbar sind.
Selbes gilt für Codes der Class-Constructor und Class-Destructor.

[Commander Tom]

40 Minuten, um zu compilieren ? Wie macht ihr das bei Änderungen im Code ? Nur einmal am Tag compilieren oder jedes Mal 40 Minuten warten ? Das ist doch nicht wirklich handelbar, oder ?

Wenn ihr ein Tool geschrieben habt, um die Units zu sortieren, dann wäre diese Erkenntnis sicher auch für andere Entwickler sehr hilfreich. Gibt es da eine generelle Strategie ? Oder war das Try and Error (bei 40 Minuten eine wohl wahrlich mühsame Geschichte)? Ansonsten würden wir uns natürlich freuen, darüber mehr zu erfahren.

Es wäre auch mal ganz interessant, auf welcher Hardware diese Compilier-Zeiten erreicht werden und ob sich da evtl. durch Aufrüsten noch was verbbessern lässt.

[himitsu]

So wie es viele große Projekte machen, wie z.B. Firefox.

Niemand kompiliert selbst, sondern es wird regelmäßig durch einen Build-Server erledigt und das Ergebnis dann irgendwo bereit gestellt.

Nightly Build, bzw. Daily Build usw.
https://de.wikipedia.org/wiki/Nightly_Build
https://de.wikipedia.org/wiki/Testautomatisierung




PS: Zwar noch nicht für den Delphi-Code, aber schonmal für den Datenbank-Teil,
hängt am GIT-Push (damals SVN-Commit) ein Event, welches einen Build-Server (CI / Continuous Integration) angestoßen, welcher eine Test-Datenbank erzeugt und verschiedene Tests laufen lässt.
Sowas kann man auch für das Erstellen machen. Bei uns werden die paar Mio Zeilen (noch mit XE, aber ich bin gerade damit beschäftigt es auf 10.4 umzustellen) eigener und fremder Code im FinalBuilder erzeugt, samt den Setups und der Hilfedateien.,
und sowas geht auch in einem Server.

Inzwischen haben wir auch ein paar GUI-Tests (noch als eigenständiges Programm > TestComplete von Smartbear).
Jetzt könnte man also automatisch in einem Server den Quellcode auschecken, über das Build-Script die Delphi-Projekte (EXE/DLL/BPL) erzeugen, jede Nacht einmal alles Tests ausführen und hätte morgens die Ergesnisse ... geht durch eine kleine Änderung irgendeine bekannte Funktion kaputt, für die es auch einen Test gibt, dann bekommt es nicht erst der Kunde mit. :stupid:




Wenn das Build/Compile dann aber nur noch über den Server liefe, dann mußt du nach einer Änderung erst bis morgen warten, bis du siehst, ob ein z.B. Semikolon fehlt. :lol:

Wir kompilieren den Großteil lokal über FinalBuilder und jeder nur noch die eine DLL/BPL/EXE im Delphi, an welcher gerade gearbeitet wird.
Das dauert im Delphi (XE mit IDESpeedPack) einige Minuten und im FinalBuilder in unter 2 Minuten (nur der Delphi-Code), da dort alle Fremdkomponenten und mehrere eigene DLL/EXE und viele der BPL parallel (multithreated) kompiliert werden.

[Ralf Kaiser]

Zitat:

Zitat von Der Bastler (Beitrag 1474578)

Wir haben derzeit knapp 3 Mio. selbst geschriebener Code-Zeilen und noch einige Imports.
Im RIO mit IDEFixPack sind wir im Optimalfall bei reichlich 6min. Sydney braucht ca. 40 min. (Ist damit aber schneller als RIO ohne IDEFixPack)

Auf welcher Hardware kompiliert ihr denn?? Bei uns läuft ein kompletter Rio Build auf dem Buildserver etwa 6 Minuten. Und das bei etwas über 2 Mio Zeilen Code und der komplette Build macht noch eine Menge anderer Sachen (verschlüsseln von Datendateien, kopieren der erzeugten Artefakte auf verschiedene Server usw). Das reine Kompilieren der Delphi Sourcen dauert unter 3 Minuten.

Wo kommen bei euch denn die 40 Minuten her?? (nur aus Interesse)

[HeZa]

Zitat:

Zitat von himitsu (Beitrag 1474622)

Darum auch meine Empfehlung möglichst nur das USES im Interface zu benutzen.

Dort steht dir Reihenfolge fest, also immer in der Reihenfolge, wie es im Code steht.
* erste Unit
* dann das was in dieser Unit steht
* dann zweite Unit (falls nicht bereits in untergeordneten Units geladen)
* usw.

Das was im USES der Implementation steht, das kann der Compiler in beliebiger Reihenfolge einbinden.

wenn ich also die Units A, B und C habe und alle 3 den Bezeichner X definieren und ich in der implementation uses A, B, C angebe und X in meiner Unit verwende, dann verwende ich unter Umständen das X aus B oder A?

*Kopfkratz*

[Bernhard Geyer]

3 Mio. Quellcodezeilen - 40 Minuten?
Kann es sein das ihr noch mit 20 Jahre alten Rechner auf Netzwerklaufwerken mit 10BASE2 arbeitet?

Kopiert ihr lokal oder Netzwerk?
Wenn Netzwerk - Wieso? Mit Git und Co ist doch eine "sichere Ablage Quellcode" so nicht nötig.
Wenn Lokal - Ach mal den Virenscanner abgeschaltet? Diese können ziemlich Mistig sein und die kompilierung durch Analyse der Zwischendateien stark bremsen.

[jaenicke]

Wir kommen auf einer CPU mit einer Einzelkernleistung von ca. 2500 Punkten im Passmark Benchmark auf über 1 Million Zeilen pro Minute bzw. 20.000 Zeilen pro Sekunde. Mit vielen Kreuzbeziehungen und Units unterhalb von implementation reduziert sich das aber teilweise drastisch auf unter 5.000. Von daher hängt die Geschwindigkeit stark vom Quelltext ab.

Extrem bremsen tun auch der Windows Defender (nur mit Aktivierung des Defenders halbiert sich hier die Geschwindigkeit fast), aber auch z.B. AVG oder Kaspersky haben ziemlich gebremst. Mit Norton sinkt die Leistung zwar auch, aber nicht so extrem.

[himitsu]

Zitat:

Zitat von HeZa (Beitrag 1474664)

wenn ich also die Units A, B und C habe und alle 3 den Bezeichner X definieren und ich in der implementation uses A, B, C angebe und X in meiner Unit verwende, dann verwende ich unter Umständen das X aus B oder A?

*Kopfkratz*

Ja, aber so lange B oder C nicht auch in A vorkommen, wird dennoch A von deiner Liste als Erstes geladen/initialisiert.

Deine Reihenfolge, aber natürlich die Abhängigkeiten zuerst.
Wenn A etwas benötigt, dann muß das ja zuerst da sein.



Dennoch bleibt insgesamt diese Reihenfolge konsistent und quasi nachvollziehbar.
Es passiert somit nicht, dass es plötzliche eine andere Reihenfolge ist, wenn du 5 Minuten später nochmal kompilierst.
(abgesehn von dem Zeugs in der Implementation)

Fehler, z.B. durch fehlende Initialisierung, sind dann nicht mal da und mal weg.
Ich hatte mal so einen Fall, dass es über Komandozeile kompiliert einen Fehler gab, aber in der IDE kompiliert war der plötzlich weg, womit er beim Debuggen nicht so schnell zu finden war. :wall:

[OlliWW]

Wir kompilieren ca. 2 Mio Zeilen mit 10.4.1 in ca. 45 Sekunden.

Wir haben in den letzten Jahren sehr viel Zeit darauf verwendet Units zu trennen, zirkuläre Referenzen zu lösen und halten die "uses" dauerhaft "sauber". Wir lassen regelmäßig vom CNPack und anderen static analyzern überprüfen, ob wir noch etwas verbessern können.

Kompiliert wird auf VMs die auf einem Intel Xeon Gold mit 3.0 Ghz laufen.

[Rollo62]

Zitat:

Zitat von OlliWW (Beitrag 1474748)

Wir kompilieren ca. 2 Mio Zeilen mit 10.4.1 in ca. 45 Sekunden.

Wir haben in den letzten Jahren sehr viel Zeit darauf verwendet Units zu trennen, zirkuläre Referenzen zu lösen und halten die "uses" dauerhaft "sauber". Wir lassen regelmäßig vom CNPack und anderen static analyzern überprüfen, ob wir noch etwas verbessern können.

Kompiliert wird auf VMs die auf einem Intel Xeon Gold mit 3.0 Ghz laufen.

+1 :thumb:

[himitsu]

Zitat:

Zitat von OlliWW (Beitrag 1474748)

Wir kompilieren ca. 2 Mio Zeilen mit 10.4.1 in ca. 45 Sekunden.

Als "eine" EXE ginge es bei uns auch schneller (vor Jahren im XE mal ausprobiert),
aber wir kompilieren hier auch ein paar Fremdkomponenten und unser Code ist auf etwa 80 DLL/BPL/EXE verteilt.
Da geht alleine schon mehr Zeit drauf, da es "viele" Einzelprojekte sind, wo sich fast überall auch noch Eurekalog ins Kompilieren reinhängt.

[Der Bastler]

Sorry für die späte Antwort, bin überrascht, dass das es so viele Rückmeldungen gab.
Ich versuche auf ein paar Punkte einzugehen:

Uns ist aufgefallen, dass der Compiler die ersten 1,5 Mio Zeilen rel. flott durchläuft (ca. 10-20 sek.) und dann aber an manchen Stellen sehr lange festhängt. Das sind meistens Zeilen aus USES im Implementation-Teil. Aber auch Zeilen aus USES im Interface-Teil. Das verstehen wir nicht ganz. (Evt. ist ja auch die Anzeige im Compilerfenster falsch oder irreführend.) Es widerspricht auch dem was himitsu schreibt:
"Das was im USES der Implementation steht, das kann der Compiler in beliebiger Reihenfolge einbinden.

Auch werden UNITs der Implementation eventuell erst nach dem Code der Initialization geladen und bereits vor der Finalization entladen,
während die UNITs im Interface immer vor Initialization geladen und erst nach Finalization entladen werden, womit deren Funktionen dort (sicher) nutzbar sind."

Danke für den Hinweis! Hier werden wir noch mal prüfen und evt. ein paar mehr "cast's" in Kauf nehmen.


* USES-Sorter-Tool: Wir analysieren alle Abhängigkeiten unserer Units voneinander(Häufigkeit; Streuung;...) jeweils nach "interface" in "implementation" und bringen diese in die optimale Reihenfolge. Eine wichtige Regel hierbei, die für unser Projekt funktioniert:
Zuerst die Units, die keine Abhängigkeiten in unser Projekt haben (Delphi-Units,...), dann die Projekt-Units sortiert nach ihren Querabhängigkeiten und zwar die mit den MEISTEN ZUERST. (Unser Tool hat hierfür Schieberegler, mit denen man die Prioritäten der Verwendungen(verwendet / wird verwendet <=> interface / implementation) einstellen und optimieren kann.)

=> Das sind aber unsere Erfahrungswerte für SEATTLE und RIO, wir wissen nicht, ob das für andere Projekte und/oder andere Compiler gilt.

Refactoring: Ja! Immer und unbedingt! Je größer und langlebiger das Projekt umso notwendiger. Unser Projekt ist über mehr als 20 Jahre stetig gewachsen und nicht immer wurde konsequent dran geblieben - leider. Der Refactoring-Prozess ist deshalb aufwändig und oft rel. komplex und hat schon unzählige Stunden verschlungen.
Er darf nicht so viel Resourcen binden, dass inzwischen die Kunden abspringen :-).

Compile-Zeiten (in Delphi eigentlich "Erzeugen"-Zeiten): Ich habe Euch Richtwerte geschrieben, die auf unseren Standard-Entwickler-Rechnern - alles lokal - so auftreten (z.B. I7-7700T 2,9GHz; 16GB RAM; Win 10 Pro). Wir erzeugen in reichlich 6 min. mit IDEFixPack. Das ist ok für uns. Manche Entwickler brauchen selten zu erzeugen, meist reichen ein oder mehrere Strg+F9 hintereinander aus.
Die 40 Minuten beziehen sich auf Erzeugen ohne IDEFixPack z.B. in SYDNEY. (Ich kann Euch gern mal ein Video machen :-)) Virenscanner spielt keine Rolle. Aber vielleicht machen wir ja auch einen anderen grundlegenden Fehler oder wir haben falsche Einstellungen in der IDE,... ?

Viele Grüße, Lars

[dummzeuch]

Zitat:

Zitat von Der Bastler (Beitrag 1475161)

USES-Sorter-Tool: Wir analysieren alle Abhängigkeiten unserer Units voneinander(Häufigkeit; Streuung;...) jeweils nach "interface" in "implementation" und bringen diese in die optimale Reihenfolge. Eine wichtige Regel hierbei, die für unser Projekt funktioniert:
Zuerst die Units, die keine Abhängigkeiten in unser Projekt haben (Delphi-Units,...), dann die Projekt-Units sortiert nach ihren Querabhängigkeiten und zwar die mit den WENIGSTEN ZUERST. (Unser Tool hat hierfür Schieberegler, mit denen man die Prioritäten der Verwendungen(verwendet / wird verwendet <=> interface / implementation) einstellen und optimieren kann.)

=> Das sind aber unsere Erfahrungswerte für SEATTLE und RIO, wir wissen nicht, ob das für andere Projekte und/oder andere Compiler gilt.

D.h. das Tool ändert nur die Reihenfolge der Units in Uses-Liste der .DPR-Datei?

Darauf muss man erstmal kommen, ist aber definitiv plausibel.

[arnof]

Anhang 53136

Viel mehr geht aktuell nicht ... Ohne Fixpack mehrere Minuten Wartezeiten in der IDE mit Fixpack ist die IDE Benutzbar (große Projekte und keine Spassprojekte); Deshalb ist 10.4 aktuell nicht richtig nutzbar für mich ...

[Delphi.Narium]

@Der Bastler

Habt Ihr mal den FileMon / ProcessExplorer mitloggen lassen, worauf Delphi beim Kompilieren zugreift, wie und wo es sich 'nen Wolf sucht?

Da sieht man dann auch alle Dateizugriffe, die ins Leere laufen, weil die gesuchte Datei an der Stelle nicht gefunden wurde und dann der Suchpfad der Reihe nach durchgegangen wird. Das kann ganz schön viel werden.

Deshalb: Suchpfade auf das wirklich erforderliche reduzieren.

Wir hatten das Thema vor einiger Zeit schonmal, eventuell hilft das weiter: https://www.delphipraxis.net/1425517-post24.html bzw. https://www.delphipraxis.net/199685-...en-finden.html

[TurboMagic]

Die Integration weitere Teile des Fixpacks ist m.W. am Laufen...
Geht halt nur nicht auf einmal, da das nicht 1:1 übernommen werden kann/sollte.