OnXXX( параметры )
{
запомнить параметры (поместить в очередь)
OnMain();
}
On2XX( параметры )
{
/*вычисления*/
поменять приоритет обработки событий (если нужно)
/*вычисления*/
промежуточный return (если нужно)
/*вычисления*/
}
void OnMain()
{
прочитать приоритет обработки событий
для каждой группы событий
извлечь параметры из очереди
OnTradeXXX( параметры )
удалить событие из очереди
}
このアイデアの初歩的なダイアグラム・コードを教えてください。一見すると、完全な誤解のように聞こえます。
OnMain関数の実行中に、現在のリアルキューの状態を知る 方法がない。これを行うための唯一の回避策は、リンク先で紹介されているようなスパイウェア・プログラムです。
最もシンプルな形で。
OnXXX( параметры ) { запомнить параметры (поместить в очередь) OnMain(); } On2XX( параметры ) { /*вычисления*/ поменять приоритет обработки событий (если нужно) /*вычисления*/ промежуточный return (если нужно) /*вычисления*/ } void OnMain() { прочитать приоритет обработки событий для каждой группы событий извлечь параметры из очереди OnTradeXXX( параметры ) удалить событие из очереди }計算のやり方そのものを変えればいいのです（タスクの要求に応じて中間戻りを何度も行う）。しかし、それが困難な場合、1ステップで、あなたにとってOnMainは存在しない（あなたはOnMainではなく、On2XXでメインコードを動かす）と考えて、それぞれOnMainでは何も学ぶ必要はありません。
松葉杖は、間違った方向に作られています。
OnXXX関数は、キュー内のイベント（パラメータ）をコピーして、メインのOnMain関数を呼び出すだけにしておきます。そのコードをすべてOn2XXの機能の複製に移動させる。そして、OnMainからこれらの複製されたOn2XX関数を必要な順序で呼び出し、順番にキューからデータをパラメータとして渡します。
そして、計測を行い、スピードの向上を示すことで、MQLを適切な機能で補完することを提案することができます。しかし、今ここですでに自分ですべてやってしまっているのに、なぜ追加するのか。
そういうことを書いているのではありません。
つまり、TRADE_TRANSACTION_HISTORY_ADD の呼び出しや最終呼び出しでも、多くのフィールドが埋められません。
その結果、すべてのトレーダーはここで、到着した瞬間にこれらの欠落したパラメータをどうにかして決定しようと苦心しているのです。
OntaredeTransaction "の機能が不十分なため、トレーダーが適切に動作するコードの開発に費やす時間と "負荷 "の両方において追加費用が発生します（つまり、コミュニティレベルで膨大な時間損失と非効率が発生します）。
現在の開発者からの回答は、「Marketの実行シンボルがあれば、価格価値はゼロになる、こうあるべき」（リンク）というようなものです。(リンク) - これは、もう一度言いますが、UNNORMALです。
最後の関数呼び出しにおける網羅的な値の欠如は、多くの余分な作業を引き起こします。
HistorySelect.
これは、めちゃくちゃ高い機能です。そして、残念ながら、今はいくらキャッシュしてもそのスピードは許容できない。
例えば、戦場のEAでは、実際のデータを使って作業することが重要です。特に、Market WatchとCopyTicksのティックが可能な限り古くなっていないこと。
そのために、あまり良くないが、現在の価格データの妥当性をチェックする仕組みが強制されている。この仕組みの一つは、あるシンボルの取引が最後のティックより後に経過したことを検出することである。このようなことはめったに起こらないので、現在のティックがまだ最新かどうかを知ることは重要なことです。
この検出のためには、最近の案件の履歴にアクセスできる必要があります。これは、HistorySelectを使用して、以下のような模式的な方法で行われます。
残念ながら、このようなHistorySelectの呼び出しには5〜30ミリ秒 かかります（Release-EX5で自分で計測しました）。Expert Advisor が OnTick でこのような更新を何度も行う場合（例えば OrderSend の後など、一時停止の後に行うべき）、すべてが非常 に高く、長くなってしまうのです。HistorySelectは1回のOnTickでまとめて数秒を食ってしまうことがあります。
開発者の皆さん、どうしてこんなに高いんですか？この機能は、適切に実装することで瞬時に実行することができます。
このようなHistorySelectの呼び出しが 5〜30ミリ秒 続く」ことについての根拠はありますか？
もし私があなたの考えを正しく理解しているなら、テストコードは次のようになるはずです。
100000クエリの仕組みはこうだ。
このようなHistorySelectの呼び出しが 5〜30ミリ秒 続く」ことについての根拠はありますか？
もし私があなたの指摘を正しく理解しているなら、テストコードは次のようになるはずです。
10万回クエリの仕組みはこうだ。
このようなHistorySelectの呼び出しが 5〜30ミリ秒 続く」ことについての根拠はありますか？
もし私があなたの指摘を正しく理解しているなら、テストコードは次のようになるはずです。
10万回クエリの仕組みはこうだ。
スクリプトを実行する
別のスクリプトを起動する。
通常の戦闘回数です。HFTではありません。
ところで、あなたのスクリプトでは、HistorySelectが毎回すべてを再計算していることがわかりました。そして、入力パラメータは変更されず、履歴テーブルも更新されず、他のHistorySelect関数も呼び出されなかったのです。
スクリプトを実行する
そうすると、詳細が必要になってきます。
私のテストは、最速ではない「Intel Xeon E5-2630 v4 @ 2.20GHz」で、バックグラウンドで他の多くのプロセスを実行したものです。
私のテスト口座の履歴では、2009年以降31315件の注文が多かれ少なかれ均等に あり、そのうち本日の注文は8件です。
スクリプトやExpert Advisorを同時に実行し、端末のデータベースを大量に読み込んでいる可能性があります。きれいな」端末で試してみてください。
より情報量の多いテスト
3本です。
そうすると、詳細が必要になってきます。
私のテストは、最速ではない「Intel Xeon E5-2630 v4 @ 2.20GHz」で、バックグラウンドで他のプロセスがたくさんある状態で実行されました。
テスト口座の履歴は、2009年以降ほぼ均等に31315件の注文があり、そのうち本日の注文は8件でした。
スクリプトやExpert Advisorを同時に実行し、端末のデータベースを大量に読み込んでいる可能性があります。きれいな」端末で試してみてください。
同じアカウントとマシンで空のターミナルを使用します。
他のアカウントや端末でも同じ絵が表示されます。コンフィギュレーションです。
読者の皆様には、このスクリプトの結果をお聞かせください。
より情報量の多いテストです。
3回スタート。
空っぽの端子2460。
ZS 空のアカウントで実行する。
スピードは注文数ではなく、取引 数に強く影響されるようです。
同じアカウントとマシンで空のターミナルを使用します。
他のアカウントや端末でも同じパターンです。コンフィギュレーションです。
このスクリプトの結果を読者に引用してもらう。
証明するものではありませんが、（別のシンボルで）新たに実行するたびに時間が増えるという事実は憂慮すべきことです......。
取引履歴の長い口座で運用する必要がある。