// Возвращает время Обзора рынка в миллисекундах.long TimeCurrentMsc()
{
long Res = 0;
MqlTick Tick;
for (int i = SymbolsTotal(true); i >= 0; i--)
{
conststring Symb = SymbolName(i, true);
if (SymbolInfoTick(Symb, Tick) && (Tick.time_msc > Res))
Res = Tick.time_msc;
}
return(Res);
}
トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム
MetaTrader 5ビルド2650の新バージョン：チャートのバックグラウンド読み込みとMQL5コードプロファイラの機能向上
fxsaber, 2020.11.04 16:50
残念ながら、チャート、ターミナル、マーケットウォッチなどのウィンドウを最小化する機能は追加されませんでした。先に、これらのウィンドウを最小化することでCPUの負荷が軽減されるという根拠が示されました。また、Terminalウィンドウが表示されていないときは、Market Watchウィンドウなどでのデータ表示を停止します。例えば、現在のアプリケーション（ブラウザなど）がアクティブで、かつ最大化されている場合などです。
ヒゲのニーズは、現在どのチャートが選択されているかを判断することです。人々はカサカサしたWinAPI ソリューションを使わざるを得ないのです。
はい、MetaTrader VPSはホスティングプロバイダーの 通常のVPSと比較して、レイテンシー（レイテンシーの排出量）が桁違いに少なく、すべてのリソースが何倍もあります。
その理由は何度も説明されている。
実行スレッドのゼロレイテンシーを保証することは、現在の（すべての）プロセッサ・アーキテクチャでは不可能です。リアルタイムシステムOS」の 話は神話として残っているので、言及する必要はないでしょう。
シングルイジェクションの意味がわかりました、詳しい説明ありがとうございます。しかし、この時点では、SymbolInfoTickについてではなく、ほとんどすべてのティックで ラッシュする、異なる性質のラグについて議論しています。
。
他の問題は、「実は他のコメントを意味していた」ということがなく、1つのコメントでシナリオが明確かつ完全に記述されている場合にのみ考慮されます。また、シングルコマンドメータリングに巻き 込まれることもありません。
他の問題は、「実は他のコメントを意味していた」ということがなく、また単一コマンドのメータリングに巻き込まれることなく、シナリオが明確かつ完全に単一のコメントで記述されている場合にのみ考慮することができます。
リンク先には、ソースコードのコメントを含む詳細が掲載されています。
トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム
MT5とスピードの関係
fxsaber, 2020.11.05 07:42
MQのVPSを使っている人、そこで以下のプログラムの結果を教えてください。
deltixというプラットフォームがあります（宣伝するわけではありませんが）。開発者に相談したところ（少し前に裁定取引につなげたかった）、単発の遅延は当たり前で、平均値を見る必要があると同じ説明を受けました
ちなみに、これは誰の違反でもなく、石を投げつけることなく
このため、Market Watch 全体の配列と、現在のポジション/注文の 配列を返す通常の関数を用意するのが合理的です。MarketBookGetと同様です。
今はサイクルを回さなければならない。これはVERY高価です。
トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム
MT5とスピードの関係
fxsaber, 2020.10.07 12:41
実用的な必要性から、そのように書くのです。
再三の要望にもかかわらず、なぜかMQL5でEAを入力しようとした。
加速度はありません。複数の加速度を証明するために、少なくとも大まかな数字で計算を提示すること。
資源の奪い合い？新しいストリームを無秩序に作り出す？何でもないことで対立する？
原因不明のスローダウンをしたいのですか？
イベントベースモデルでは、すべてのイベントは常に1つずつ形成されて行っています。チューイングアップ - チューイングアップ。
ユ ーザープログラム、特にそのハンドラの処理を高速化。そういうことなんです。
スレッドの使用を最小限にしようとしていることは理解できます。しかし、代替案の1つとして、各ハンドラを別々のスレッドで実行する方法があります。
無秩序にスレッドを作成しない。ユーザープログラムでは、ハンドラは数個しかなく、それぞれがプログラム開始時に独自のスレッドで起動する必要があります。
そして、ハンドラ間のイベントをミューテックスなどで同期させるのです。
しかし、スレッドが面倒であれば、おっしゃるとおり、シングルスレッドで作業できるイベントモデルがあります。イベント処理、タスクトリガーによるイベントループで。
イベントループは、順次実行されますが、このループ内のタスクは並列に処理 されます
つまり、プログラム内のすべてのハンドラがこのイベントループの中で実行されると、すべてのイベントが非同期でリアルタイムに同時に到着することになるのです。
つまり、OnTrade とOnBookの同じ イベントがマッチングされます。
イベントループが他の言語でどのように 機能するかは、お問い合わせください。
イベントループが すでに端末に存在する場合は、プログラム中のハンドラに適用すればよい。以上です。
各ハンドラは別々のスレッドで実行 される必要があります。
問題は何一つ解決していない。例えば、異なるスレッドが内部変数へのアクセスを読み取る場合、MQLプログラムはより複雑なものになります。
問題は何一つ解決していない。例えば、異なるスレッドから内部変数に読み書きアクセスする場合、MQL-Programは桁違いに複雑になります。
MQLプログラムがより複雑になるわけではなく、開発者にとって同期が頭痛の種になるだけです。もちろん、彼らはそれを解決しようとはしませんが。
あるいは、このモデル用に設計されていないプロジェクトの初期アーキテクチャがデッドロックしている場合。
また、新しいモデルのためにプロジェクトを書き直す人はもちろんいないでしょう。
イベントループモデルは、ハンドラに向いています。これが私が言いたかったことです。
そしてこのモデルは、以前から 端末に存在していた可能性が高く、ハンドラに適用されていなかっただけなのです。
MQLのプログラムがこれ以上複雑になることはないだろう...。
ここで実践と交わることのない理論付けは、これで終わりにした方がいいと思います。