IDE bei FMX Debuggen langsam

[firstfriday]

Hallo Zusammen,
ich habe D12 auf mehreren Rechner installiert, aber bei den schnellsten Rechnern läuft beim Starten und Beenden (F9) bei FMX Apps das Loaden und unloaden der IDE unerträglich langsam.
Aber nur beim Debuggen, die compilierte Version ist schnell.
Hat jemand eine Idee wo ich da ansetzen könnte?

[freimatz]

Exceptions? (auch behandelte)

[firstfriday]

Nein, es liegt an der IDE. Auch wenn kein Code ausgeführt wurde (z.B. nur leeres Fenster) und dann auf Stopp(Program Reset) dauert es ewig bis er zurück kommt. Je mehr Fenster desto länger.
Und wie gesagt, auf anderen Rechnern ist das nicht so. Es muss irgenwas mit dem Debugger zu tun haben und speuifisch mit dem Rechner oder DirectX, da nur bei FMX.

[Nakor]

Ich habe das gleiche Problem. Aber ich konnte ebenso wie firstfriday Unterschiede feststellen:
Als Testprojekt habe ich das "Settings Project" aus den Samples genommen. Auf einem 14"-Zoll Notebook (Intel Proz von 2015) läuft das Programm im Debugger von Delphi 12.1 als Win64-Anwendung flott und ohne längeres Einfrieren der IDE. Ebenso auf einem Rechner mit einem alten Athlon-Prozessor und angeschlossenem 21"-Monitor.
Die Probleme habe ich nur auf dem Rechner (aktueller Ryzen-Prozessor) mit 34"-Monitor.

[MichaelT]

DX9 vs. DX10? Gibt es eine Setting 'UseGlobalWasderTeufelWas' welches vor dem Application Initialize zu setzen ist.

Irgendwie erinnert mich das so an DirectX oder riecht verdächtig danach. Mein alter Laptop rechnet teils auf der AMD Grafikkarte, nicht in Betrieb in dem Sinne und es läuft alles akzeptabel schnell.

FMX Anwendungen waren über alle Rechner hinweg bei mir immer ein wenig behäbiger. Aber ich machte Tests gegen den Mac und OS/X und somit war das Verhalten von noch mehr Faktoren beeinflussbar. Ich hatte halt gerne Medion PCs, halt nur nicht das Keyboard, mit leisen AMD Prozessoren und leicht zu tauschenden Lüftern. Bei den Rechnern trat solch eine Latenz vor Jahren auf, aber die hatten auch 5400rpm drehende Festplatten.

Bei jungfräulichen, sprich frisch ausgepackten Rechnern, ist auffällig, dass das RAD Studio beim Starten und Debugging der Prozessor in den Turbo Boost Mode geht und bläst wie Sau und auch bei leeren VCL Anwendungen. Das Visual Studio steht dem um nichts nach.

Mir hängt Windows mittlerweile beim Hals raus. Wäre der Verursacher allein das RAD Studio, dann ließe sich so ein Verhalten leichter eingrenzen.

--

Wobei ich mich bei den Menschen hier im Forum für die angeregte Diskussion bedanke und mich bezüglich Delphi endgültig vom Acker mache. Gibt eh genug Leute, die froh sind, wenn ich weiter bin und nicht nur ich.

Auf jeden Fall 'Alles Gute' in die Runde.

Zitat von firstfriday:

Nein, es liegt an der IDE. Auch wenn kein Code ausgeführt wurde (z.B. nur leeres Fenster) und dann auf Stopp(Program Reset) dauert es ewig bis er zurück kommt. Je mehr Fenster desto länger.
Und wie gesagt, auf anderen Rechnern ist das nicht so. Es muss irgenwas mit dem Debugger zu tun haben und speuifisch mit dem Rechner oder DirectX, da nur bei FMX.

[himitsu]

Vieles nutzt inzwischen im Windows eigentlich Direct2D und neuerdings wird gern Skia verwendet.
Auch gibt es einen Unterschied zwirsch den Platformen (unter iOS war es, glaub ich, Metal-Irgendwas)