Leinwand vs. Etiketten - Seite 8

 
Nikolai Semko:

Ja, ich habe nicht gesehen, dass es ein internes Diagramm ist.
Nach dem Profiling zu urteilen, liegt die Ursache für die Bremsen beim Scrollen des Diagramms in dieser Zeile:

Profiling mit aktivem Scrollen:

Profiling mit aktiver Mausbewegung ohne Scrollen (ohne gedrückte LKM):

ZS: Die Quelle der Bremsen sind also doch nicht die Kanvas, sondern die Objekte.

Leider ergibt mein Profiling dieses Codes eine Leerstelle. b2828.

 
fxsaber:

Leider ergibt mein Profiling dieses Codes eine Leerstelle. b2828.

Es sieht so aus, als ob sie den Profiler noch nicht fertiggestellt haben. Ich habe auch manchmal eine Leerstelle bekommen. Aber jetzt funktioniert es.

Es funktioniert auch mit diesem hier.

 
Renat Fatkhullin:

Das ist der falsche Ansatz. Zumal der visuelle Tester ein anderes, verzögertes Rendering-Modell verwendet, um den Testprozess nicht völlig zu verlangsamen.

Verstehe. Sie müssen also nichtnur im Prüfgerät, sondern auch in der Karte messen.

Renat Fatkhullin:

Das habe ich nicht gesagt.

Ich habe auf die offensichtlichen Fehler hingewiesen und erklärt, wie das Rendering-System funktioniert.

Dann habe ich alles falsch verstanden. Entschuldigung.

 
Nikolai Semko:

Es sieht so aus, als ob sie den Profiler noch nicht fertiggestellt haben. Ich habe auch manchmal eine Leerstelle bekommen. Aber jetzt funktioniert es.

Das hier funktioniert auch.

Bei b2830 habe ich auch nichts gefunden.

 
Igor Makanu:

mit dem Windows-Ereignismodell - selbst wenn Sie die Maus schnell bewegen, beginnt die CPU-Last zu steigen, unabhängig davon, welche Anwendung im Fokus war

SZY: Ich habe es im Task-Manager von Win10 überprüft... Aus irgendeinem Grund wird kein Anstieg der CPU-Last angezeigt, in Win7 stieg genau die gleiche Last an, wenn ich die Maus schnell bewegte - ich bezweifle, dass Win10 das Ereignismodell drastisch geändert hat, höchstwahrscheinlich arbeitet der Task-Manager auf eine andere Weise

Vin10. Hier ist der Plot, wenn ich die Maus im Eingabefenster dieser Textnachricht bewege und die LKM gedrückt halte


Hier ist es ohne das LKM


 
Aleksey Mavrin:

Vin10. Hier ist der Plot, wenn ich die Maus im Eingabefenster dieser Textnachricht bewege und die LKM gedrückt halte


Hier ohne das LKM.


nicht selbstverständlich

Hier ist der virtuelle Desktop mit Win7 - wenn ich die Maus nicht bewege, belastet er die CPU 3-4%

wenn sich die Maus schnell bewegt - 11-14% Last

Ich meine, dass Message Queue in Win immer verarbeitet werden muss, aber es ist extra CPU-Zyklen - Google "C++ Windows-Fenster" - jedes Handbuch für das Schreiben von Windows Windows-Anwendung in C++ mit WinAPI, lesen Sie dort über Message-Handler

 
Igor Makanu:

nicht illustrativ.

von einer virtuellen Maschine unter Win7 - wenn Sie die Maus nicht bewegen, 3-4% Last auf der CPU

wenn sich die Maus schnell bewegt - 11-14% CPU-Last

Ich meine, dass die Nachrichtenwarteschlange in Win immer verarbeitet werden muss und zusätzliche CPU-Zyklen benötigt - googeln Sie "c++ windows window".

Um es in Zahlen auszudrücken: Ich tue nichts - 10-15 schwankt, 17-30 bei Bewegung.

Aber sollte dies dazu führen, dass OnTimer um den Faktor 2 langsamer wird, nein, natürlich nicht, es sei denn, die Auslastung liegt bei 95-99%.

Wenn Sie ein Handbuch zum Schreiben von Windows-Fensteranwendungen in C++ mit WinAPI haben, lesen Sie dort über Message-Handler

Der Message-Handler beansprucht ohnehin nur einen Bruchteil der CPU, er wird nur nicht benutzt, wenn keine Warteschlange vorhanden ist. Für MT-Prozesse sollte es bei dieser Belastung keine Verringerung der CPU-Zeit geben.
 
Aleksey Mavrin:

Aber sollte es OnTimer um das Doppelte verlangsamen, nein, natürlich nicht, außer bei 95-99% Last.

Timer ist auch ein WinAPI-Ereignis, aber ich bezweifle, dass jedes MQL-Programm den Systemtimer abonniert - er emuliert die MQL-Umgebung(virtuelle Maschine)

Aleksey Mavrin:

Message-Handler nimmt CPU-Anteil und so weiter, nur nicht verwendet, wenn es keine Warteschlange gibt. Für MT-Prozesse sollte es bei dieser Belastung keine CPU-Zeitabschaltung geben.

Es gibt immer eine Warteschlange an einem aktiven Fenster, und es ist eine übliche Vermutung, wie diese Warteschlange vom Terminal zwischen Diagrammen und dann zwischen MQL-Programmen verteilt wird.


gut, am Ende - ein Monopol-Modus zu erhalten und nicht auf Nachrichten zu verarbeiten - nicht viele Möglichkeiten, die erste, die kommt - exklusive Vollbild-Modus-Anwendung, aber das ist eine andere Geschichte, als ob der "Kampf um Ressourcen PC", dann brauchen Sie nur eine API, um den Austausch zu gehen und schreiben Sie Ihre Anwendung, und dort registrieren Sie das Fenster oder nicht


ok, ich bin nicht daran interessiert, nach Spitzen-CPU-Last zu suchen - solange wir in Vin sind, kann alles passieren, ich bin im Allgemeinen damit einverstanden

 
Igor Makanu:

Timer ist auch ein WinAPI-Ereignis, aber ich bezweifle, dass jedes MQL-Programm den Systemtimer abonniert - er emuliert die MQL-Umgebung(virtuelle Maschine)

Wenn Sie sich daran erinnern, dass es einen Fehler mit Timer und Anzahl der Handler im Terminal gab, deutet dies indirekt darauf hin, dass jeder Timer in MT ein System-Winplay sein könnte

 
Auf MT4 ist die Situation interessanter(der Code ist plattformübergreifend) - OnTimer wird nicht mehr aufgerufen, wenn sich die Maus bewegt.