mql5言語の特徴、微妙なニュアンスとテクニック - ページ 49

新しいコメント
 
fxsaber

if, else, while, for, doの直後にTABキーを押すと、ちょっとだけ余計な構造が...。


mqlを知り始めて5年目にしてわかったことです。

 

ある問題 提起についてのSDでの会話からの結論。

文字列変数に値を代入するのは、非常に高価な操作であることが判明した。

そのため、開発者がコンパイラのこの点を改善するまで、できれば避けることが望ましいのですが、すぐに改善されるとは思えません。


例として、FIBOで1ヶ月間リアルティックを実行した場合、約100万ティックになります。各ティックでPositionGetStringの値を取得し、何かと比較するのであれば、パフォーマンスは問題ないでしょうが、比較する前にまず関数の結果を文字列変数に代入すると、実行時間が1秒程度長くなります。


もし、それが小さなことに思えるなら、それは間違ったビジョンです。このようなEAを最適化モードで数千回実行すると、その1秒は待ち時間の延長になる。例えば、無害な文字列の割り当てが、最適化の際にさらなる待ち時間を発生させることがあります。このニュアンスに注意し、考慮してください。


kodobaseには、同じ取引ロジックの異なる実装において、このような障害を検出するための小さなツールがあります。高速なコードを書く。

 
fxsaber

ある問題 提起についてのSDでの会話からの結論。

文字列変数に値を代入するのは、非常に高価な操作であることが判明した。

そのため、開発者がコンパイラのこの点を改善するまで、できれば避けた方が望ましいのですが、すぐに改善されるとは思えません。


例として、FIBOで1ヶ月間リアルティックを実行した場合、約100万ティックになります。各ティックでPositionGetStringの値を取得し、何かと比較するのであれば、パフォーマンスは問題ないでしょうが、比較する前にまず関数の結果を文字列変数に代入すると、実行時間が1秒程度長くなります。


もし、それが小さなことに思えるなら、それは間違ったビジョンです。このようなEAを最適化モードで数千回実行すると、その1秒は待ち時間の延長になる。例えば、無害な文字列の割り当てが、最適化の際にさらなる待ち時間を発生させることがあります。このニュアンスに注意し、考慮してください。


kodobaseには、同じ取引ロジックの異なる実装において、このような障害を検出するための小さなツールがあります。簡単なコードを書いてください。

ありがとうございます、まさかとは思いましたが。今後の開発に活かしていきます

 

寝る前の簡単ななぞなぞ、なぜ黄色い結果が出るのか？

struct INT
{
  int Array[];
  
  INT()
  {
    Print(__FUNCTION__); // до сюда не дойдет
  }
};

void OnStart()
{
  INT i = {0};
  
  Print(ArrayResize(i.Array, 5)); // -1
}
 
fxsaber:

寝る前の簡単ななぞなぞ、なぜ黄色い結果が出るのか？

コンストラクタではなく、構造体をゼロでパックしているため、配列構造体の初期化が間違っており、arrayresizeは そのような配列を好まず、私のコードはそのようなリサイズでクラッシュしました。
 
コンビナート です。
コンストラクタではなく、構造体がゼロでパックされているため、配列構造体が誤って初期化され、arrayresizeはそのような配列を好まず、私のコードはそのようなリサイズで全くクラッシュしました。

みんなが知っていることだからいいんです。

 
スラバ：

GetMicrosecondCountを指します。サーバーの速度が低下しているかどうかを判断する明確な方法はありません。間接的な効果があるかもしれません。そのため、システムネイティブのGetTickCountを使用するのがよいでしょう

GetMicrosecondCountは、短時間のコード実行を測定するために使用します。大量の OnTick 実行を測定するには、GetTickCount を使用するのがよいでしょう。

安定した結果が得られる場合は、GetTickCountの代わりにGetMicrosecondsCountを使用するようにしてください。こ こで教えてもらうことになる。心配しすぎかもしれませんね。

GetMicrosecondsCountを複数回呼び出すと、テスターでひどい遅延が発生するという仮説が正しいことがわかりました。ただし、GetTickCountも 同じ効果があります。
 
fxsaber

ある問題 提起についてのSDでの会話からの結論。

文字列変数に値を代入するのは、非常に高価な操作であることが判明した。

そのため、開発者がコンパイラのこの点を改善するまで、できれば避けた方が望ましいのですが、すぐに改善されるとは思えません。


例として、FIBOで1ヶ月間リアルティックを実行した場合、約100万ティックになります。各ティックでPositionGetStringの値を取得し、何かと比較するのであれば、パフォーマンスは問題ないでしょうが、比較する前にまず関数の結果を文字列変数に代入すると、実行時間が1秒程度長くなります。


もし、それが小さなことに思えるなら、それは間違ったビジョンです。このようなEAを最適化モードで数千回実行すると、その1秒は待ち時間の延長になる。例えば、無害な文字列の割り当てが、最適化の際にさらなる待ち時間を発生させることがあります。このニュアンスに注意し、考慮してください。


kodobaseには、同じ取引ロジックの異なる実装において、このような障害を検出するための小さなツールがあります。簡単なコードを書いてください。

struct STRUCT
{
  string Str;
  
  string Get() const { return(this.Str); }
};

void OnStart()
{
  STRUCT Struct;
  
  Print(Struct.Str);
  Print(Struct.Get()); // Выполняется гораздо дольше, чем предыдущая строка
}
 
fxsaber

文字列変数に値を代入するのは、非常に高価な操作であることが判明した。

...

比較する前にまず関数の結果を文字列変数に代入してから比較すると、実行時間が1秒程度長くなる。

私が思うに、問題は高価な代入ではなく、コンパイラがこの不要な代入をカットすべきなのに、なぜかカットしないことにあるのだと思います。つまり、コンパイルされたコードはどちらの場合も同じであるべきなのです。
 
アレクセイ・ナヴォイコフ
私の理解では、高価な代入が問題なのではなく、コンパイラがこの不要な代入をカットすべきなのに、なぜかカットしてくれないことが問題なのだと思います。つまり、コンパイルされたコードはどちらの場合も同じであるべきなのです。

これは些細な問題です。そうです。コンパイラのオプティマイザは、このような文字列の瞬間を最適化する方法をまだ知らないのです。しかし、速度低下の問題があるのは、文字列の割り当ての方だ。

コンパイラで最適化できないコードを書き、同時にその中で代入を行う。そして、スローダウンの正体が見えてくる。

構造体の文字列フィールドを関数で読み取る例は、まさにMT4/5で実装されている位置プロパティの 読み取りの方法と同じです。

MT4では、同じOrderSymbol()でもMT5で実装されているとブレーキがかかる。開発者自身がリンクで文字列を関数に渡そうとする。

したがって、次のような書き方をすると

if ((OrderSymbol() == Symb) && (OrderMagicNumber == Magic))

一般的な条件の最後にOrderSymbol()の条件を置くとよいでしょう。


TesterBenchを使用すると、一見滑らかな表面で明らかに速度が低下することに気づきました。

1...424344454647484950515253545556...247
新しいコメント
理由: