Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
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.
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.
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.
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.
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.
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
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
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
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)
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
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