ビルド 600 の注文は高速

巷ではさんざん悪口を言われている MT4 ビルド 600 ですが、そんな出来の悪いビルド 600 にも、少しはいいところだってあります。

その一つが、注文の遅延が少なくなっているという点。

以前に弊社のウェブサイトで「注文の高速化」という記事を書きました。

簡単に言うと、ビルド 600 になる前は、

• 注文関数を呼び出してから 30 秒以内に次の注文関数を呼び出すと遅延が少ない
• ただし、それ以上の間隔が空いたり、あるいは初回の注文関数は遅延が大きい

という性質があったので、注文を極限まで高速化するには、28-29 秒に一回くらいのペースで、ダミーの注文変更関数を実行し続ける必要がありました。

しかし、ビルド 600 では、そのあたりの認証処理が改善されたため、そんな高速化の工夫はもはや不要です。

このことは、ビルド 600 のアナウンスにおいても、次のようにサラッと説明されています：

Terminal: Changed the algorithm of placing trade requests. In previous builds, an additional network connection has been created when placing trade requests. This connection has remained active for some time after a last trade request was sent in order to provide fast sending of a large number of trade requests.

Now, when placing trade requests, all of them are passed via the main connection with the trade server. Thus, the time of processing the trade requests (especially the first one) has been considerably reduced as there is no need to wait for connection to the trade server being established any more. In order for the new request sending algorithm to be operable, the trade server should also be updated - requests are still set in a separate connection on older trade servers.

ビルド 610 でテスト

では、実際に簡単なスクリプトを書いて、本当かどうかを確認してみることにします。

指定されたミリ秒間隔で、絶対に約定しない価格に指値注文を何度か発注し、それぞれの遅延時間を表示するスクリプトです。

#property copyright "Copyright 2014 Softgate Limited."
#property link      "http://www.softgate.co.jp/"
#property version   "1.00"
#property strict
#property show_inputs

extern int Delay = 35000;
extern int LoopCount = 5;

void OnStart()
{
  uint pre, post;
  for (int i = 0; i < LoopCount; i++)
  {
    pre = GetTickCount();
    int ticket = OrderSend(Symbol(), OP_SELLLIMIT, 0.1, Bid + 10000 * Point, 5, 0, 0);
    if (ticket != -1)
    {
      post = GetTickCount();
      Print("Interval: " + DoubleToStr(Delay / 1000.0, 0) + 
        " s, Order Delay: " + IntegerToString(post - pre) + " ms");
      OrderDelete(ticket);
      Sleep(Delay);
    }
  }
}

最初は、ループの間隔を 35 秒にして実行します。

次に、ループの間隔を 25 秒にしてみます。従来ならば、35 秒間隔のときよりも注文の遅延が少なくなるはずなのですが…

結果的にはほとんど変化がありませんね。

初回とそれ以外の注文において遅延時間が明らかに異なる、という現象も起きていないように見えます。

ビルド 509 でテスト

では、似たようなスクリプトをビルド 509 でも実行してみましょう。まずは、ループ間隔 35 秒の結果です。

35 秒間隔なので、初回とそれ以外が異なるという現象は起きないはずで、それはその通りですが、上記のビルド 610 の時よりも平均的に遅延が大きいようです。

次に、ループ間隔 25 秒の結果も見てみます。

ループ間隔 25 秒の場合は、確かに、初回よりもそれ以降の注文の方がやや遅延が少なくなっていることが分かります。

総評

上記の実験は、どちらも同じ国内ブローカーのデモアカウントで実行したのですが、ビルド 600 の方が

1. 初回とそれ以降の注文に遅延のばらつきが無い
2. そもそも注文の遅延がビルド 509 よりもかなり少ない

という点において、ビルド 509 よりも優れていると言えるでしょう。

まあ、なにかと出来の悪いビルド 600 系ですが、この混乱が落ち着けば そんなに悪いことばかりではないかもしれませんよ。