キャンバスとラベルの比較 - ページ 8

 
Nikolai Semko:

ああ、内部チャートだとは思わなかったよ。
プロファイリングから判断すると、グラフをスクロールしたときのブレーキの原因は、このラインにありますね。

アクティブスクロールによるプロファイリング。

スクロールを行わず、マウスをアクティブに動かした状態でのプロファイリング(LKMを押さない状態)。

ZS: ブレーキの源は、やはりカンヴァスではなく、オブジェなのですね。

残念ながら、このコードのプロファイリングは空白になりました。b2828.

 
fxsaber:

残念ながら、このコードのプロファイリングは空白になりました。b2828.

プロファイラーが まだ完成していないようですね。私も時々空白になることがありました。でも、今はうまくいっています。

これでもかというほど効きます。

 
Renat Fatkhullin:

これは間違ったアプローチです。特にビジュアルテスターは遅延レンダリングモデルが異なるので、テストプロセスを完全に遅らせることができないように。

なるほど、テスターでの測定に 加え、チャートでの測定が必要になるわけですね。

Renat Fatkhullin:

そんなこと言ってませんよ。

明らかな誤りを指摘し、レンダリングシステムの仕組みを説明しました。

じゃあ、私は勘違いしていたんですね。すみません。

 
Nikolai Semko:

プロファイラーが まだ完成していないようですね。私も時々空白になることがありました。しかし、現在は動作しています。

こちらも有効です。

b2830でも何も出ませんでした。

 
Igor Makanu:

Windowsのイベントモデル で、マウスを素早く動かすと、どのアプリケーションにフォーカスがあっても、CPUの負荷が 増加し始める。

SZY: Win10のタスクマネージャーで確認したところ...。Win7ではマウスを素早く動かすと全く同じ負荷がかかっていたのに、なぜかCPU負荷の上昇が見られない。Win10ではイベントモデルが大幅に変更されたとは思えないので、おそらくタスクマネージャの動作が異なるのだろう

Vin10です。このテキストメッセージの入力ウィンドウで、LKMを押しながらマウスを動かすと、次のようなプロットが得られます。


LKMなしはこちら


 
Aleksey Mavrin:

Vin10です。このテキストメッセージの入力ウィンドウでLKMを押したままマウスを動かすと、次のようなプロットが得られます。


こちらはLKMなし。


わかりにくい

Win7での仮想デスクトップです。マウスを動かさないと、CPUに3~4%負荷がかかります。

マウスが速く動いている場合 - 11-14%の負荷

つまり、Winのメッセージキューは常に処理される必要がありますが、それは余分なCPUサイクルを必要とします。

 
Igor Makanu:

図解しない

Win7で仮想マシンから、マウスを動かさない場合、CPUに3〜4%の負荷がかかる

マウスの動きが速い場合 - CPU負荷11~14%。

つまり、Winのメッセージキューは常に処理される必要があり、CPUサイクルを余分に消費するのです。

もっとわかりやすく数字で言うと、何もしていないのに、10~15が変動し、動くと17~30になる。

しかし、これでOnTimerの速度が2倍遅くなるかというと、もちろんそうではなく、95~99%の負荷のときを除けば、そうなります。

C++でWinAPIを使ってWindowsのウィンドウ・アプリケーションを書くためのマニュアルがあれば、メッセージ・ハンドラについて読んでみてください。

メッセージハンドラは、キューがないときには使われないだけで、そのままではCPUの何分の一かを消費します。MTプロセスでは、この負荷によるプロセッサ時間の短縮はないはずです。
 
Aleksey Mavrin:

しかし、それによってOnTimerが2倍遅くなるかというと、もちろんそうではなく、95〜99%の負荷の場合を除けば、そうなります。

timerもWinAPIイベントですが、すべてのMQLプログラムがシステムタイマーをサブスクライブしているかどうかは疑問です - これはMQL環境(仮想マシン)をエミュレートしています

Aleksey Mavrin:

メッセージハンドラがCPUを占有するなど、キューがないときには使われないだけです。MTプロセスの場合、この負荷ではCPU時間のカットはないはずです。

アクティブなウィンドウには常にキューがあり、このキューがターミナルによってチャート間やMQLプログラム間でどのように分配されるかは、一般的なコーヒーリーフの推測に過ぎません。


まあ、最終的には - 独占モードを取得し、メッセージを処理しないように - 多くのオプションは、来る最初の - 排他的なフルスクリーンモードのアプリケーションが、それは別の話だ、"リソースのPCのための戦い "のように、その後、ちょうど交換に行くとあなたのアプリケーションを書くためにAPIを必要とし、そこにウィンドウかどうかを登録することです


CPU負荷のピークを探すことには興味がない。Vinにいる限り、何が起こっても不思議ではない。

 
Igor Makanu:

timerもWinAPIイベントですが、すべてのMQLプログラムがシステム・タイマーをサブスクライブしているかどうかは疑問です。

端末のタイマーとハンドラの数に関するバグがあったことを思い出すと、MTの各タイマーがシステムワンプレイである可能性を間接的に示唆しています。

 
MT4では、状況はより興味深いです(コードは クロスプラットフォームです) - OnTimerは、もはやマウスが移動したときに呼び出されることはありません。