10.4 Sydney IDEFixpack kommt da noch was ?

[jbg]

Zitat von 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.

Was man recht "schnell" machen könnte, wären die Einführung von HashTables als Ersatz oder als Cache für die vielen LinkedLists im Compiler. Aber bitte nicht wieder so wie bei XE2, wo HashTable eingeführt wurden, die mehr Zeit mit dem HashTable-Overhead verbringen, als mit den eigentlichen Daten. Man muss nicht Speicher reservieren und durch die Gegend kopieren, wenn man einen Eintrag sucht.

Dann gibt es noch die Einzel-Funktions-Beschleunigungen, bei denen einzelne Funktionen durch schnellere ersetzt wurden oder die für den Fall, der am meisten Eintritt, optimiert weurden. Die lassen sich (theoretisch) sogar Unittesten.

Auch recht "einfach" lassen sich die "Invarianten Code aus Schleifen entfernen" Patches umsetzen. Das macht vor allem den WIn64 Compiler einen Ticken schneller.


Kompliziert wird es bei den IDEFixPack Patches, die algorithmische Änderungen durchführen oder die Funktionsübergreifend arbeiten (in einer Funktion Informationen sammeln und in einer späteren Funktion diese nuten).

[stahli]

Zitat von 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

Aber Vorsicht vor "Pfade bereinigen" (oder wie das hieß).
Früher hat das jedenfalls mal Delphi lahm gelegt...

[Delphi.Narium]

Im FileMon kann man gut sehen, wo Dateien gesucht werden und wo sie gefunden werden.

Wenn nun in den Pfaden Verzeichnisse sind, in denen grundsätzlich nichts gefunden wird, kann man die schon bereinigen.

Die Verzeichnisse, in denen Delphi "sein eigenes Zeug" findet. lässt man natürlich in den Suchpfaden drinne, auch wenn bei einem Projekt konkret eventuell mal nix von dort benötigt wird.

Und:
Unter Pfade bereinigen meine ich eine menschliche, individuelle Bereinigung, nicht die, die die IDE selbst anbietet.

[himitsu]

Beim Pfad-Bereinigen gab es das Problem, dass Pfade mit Variablen gelöscht wurden, weil die Variablen nicht durch Platzhalter ersetzt und erst damit dann gesucht wird.

Das betrifft z.B. die Platform/Compiler-abhängigen Pfade.

[Uwe Raabe]

Sollte aber in 10.4.1 nicht mehr vorkommen: http://docwiki.embarcadero.com/RADSt...enswerte_Fixes

Zitat:

Kleinere, aber nennenswerte Fixes
"Ungültige Pfade löschen" sollte nun keine gültigen Pfade mehr entfernen.
Das Verschieben von Symbolleisten verursacht keine Probleme mehr.

[himitsu]

Gleich mal ausprobieren?

Per se sind diese Pfade ja wirklich nicht "gültig". (wenn man es nicht mit allen möglichen Werten oder einfach "*" probiert)
Und neee, es ist wie es ist ... die fliegen weiterhin raus, sowohl 10.4 als auch 10.4.1

[Uwe Raabe]

Zitat von himitsu:

die fliegen weiterhin raus, sowohl 10.4 als auch 10.4.1

Dann solltest du das mit einem entsprechenden Beispiel in RSP-14689 über Dispute resolution melden.

[Der Bastler]

Zitat von dummzeuch:

Zitat von Der Bastler:

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.

Nicht in der .DPR-Datei. In allen eigenen Units die USES-Reihenfolge in "interface" und "imlementation".

ACHTUNG! "...Querabhängigkeiten und zwar die mit den WENIGSTEN ZUERST" => die Info war falsch! Genau anders herum, sorry.

Also: 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.
------------------------

[Der Bastler]

Zitat von 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

Ja. Keine Units, die nicht verwendet werden, einbinden. Das kann man mit diversen Tools herausfinden (z.B. mit ICARUS; der sagt auch, welche Units von "interface" nach "implementation" geschoben werden können).

[OlliWW]

Aber mal zurück zur eigentlichen Frage:
Kommt da noch was?

Die 10.4.1 IDE hat bei uns noch solch schwerwiegende Bugs (STRG + Mausklick auf eine procedure dauert manchmal Minuten bis ich die Methode komme - selbst bei kleinen Projekten mit 2 Units oder eine Methode markieren, STRG + C, STRG + SHIFT + F führt zum einfrieren der IDE....) dass ich derzeit die 10.4.1er Version nicht in unserer Firma ausrollen kann.

Die Probleme sind tatsächlich so schwerwiegend, dass wir nach 20 Jahren uns nach Alternativen zu Delphi umsehen müssen, da wir ohne ein IDE Fixpack tatsächlich nicht produktiv arbeiten können und auf 10.3. hängen zu bleiben, ist auch keine gute Alternative.