同じ動作をさせる条件において、多くの "or"(|)を避けることは可能でしょうか? - ページ 6

 
Meat:

borilunad 関数呼び出しは、不必要なブレーキをかけることになります。したがって、最高速度を求めるのであれば、一文字の演算を行う Request() はすべて取り除くべきです。 ループについても同様です。 ループ内での条件チェックは、単に if() をネストしたものよりも常にはるかに遅くなります。

だから、互いに排他的な条件でも、if(A || B || C || D)アクションを使えばよくなるのです。

でも、その条件に含まれる、その時点で多くのデータをチェックする必要があるので、関数呼び出しは避けられないんです。

実験を続けることで、もしかしたら何か得られるかもしれない。しかし、拡散はどうしようもない!:)

 
一般的には、一番早い選択肢はこれでしょう。
bool result;
if (A) result=true;
else
if (B) result=true;
else
if (C) result=true;
else
if (D) result=true;
else result=false;

if (result) Action();


ただし、else result=falseの行は、最初の行と組み合わせた方が、速度に影響しない。一般に、A、B、C、Dに単純な条件(すべての数学関数などを呼び出さず、最小限の演算で済む)が含まれていれば、このような最適化による性能向上はあまり期待できません(もちろん、この構造が何千万回と実行されない限り)。 しかしコードのオーバーロードは大きな意味を持つ場合があるのです。

私は、あるスレッドで、すべては合理的に処理されなければならないと書きました。 なぜか、あなたのコードは、より重要な場所に満ちているようです。 最適化は、本当に大きな性能向上を与えるでしょう。 あなたは、基本アルゴリズムから始めるべきです。 ほとんどの初心者は、TSまたはオープンオーダーに関するすべての条件を毎ティックで チェックするのがばかばかしいです。しかし、ほとんどの場合、例えば、高値や安値がある値に達したときや、新しいバーが現れたときなど、境界条件だけをチェックすれば十分です。 その後で、さらにチェックを行うことができます。

まあ、リソースを大量に消費する計算の他は、これらの計算をDLLに移行することを考える必要がありますね。そうでなければ、クソMQL4で13分も待たされるのは(2~3分で同じ結果が得られるのに)不幸なことだと思います :)

 
Meat:
一般的には、一番早い選択肢はこれでしょう。

ただし、else result=falseの行は、最初の行と組み合わせた方が、速度に影響しない。一般に、A、B、C、Dに単純な条件(すべての数学関数などを呼び出さず、最小限の演算で済む)が含まれていれば、このような最適化による性能向上はあまり期待できません(もちろん、この構造が何千万回と実行されない限り)。 しかしコードのオーバーロードは大きな意味を持つ場合があるのです。

私は、あるスレッドで、すべては合理的に処理されなければならないと書きました。 なぜか、あなたのコードは、より重要な場所に満ちているようです。 最適化は、本当に大きな性能向上を与えるでしょう。 あなたは、基本アルゴリズムから始めるべきです。 ほとんどの初心者は、TSまたはオープンオーダーに関するすべての条件を毎ティックでチェックするのがばかばかしいです。しかし、ほとんどの場合、例えば、高値や安値がある値に達したときや、新しいバーが現れたときなど、境界条件だけをチェックすれば十分です。 その後で、さらにチェックを行うことができます。

まあ、リソースを大量に消費する計算の他は、これらの計算をDLLに移行することを考える必要がありますね。そうでなければ、クソMQL4で13分も待たされるのは(2~3分で同じ結果が得られるのに)不幸なことだと思います :)

最速のオプションはパコが提案した
 
tara:
最速のオプションはパコが提案した

複数の値を毎回合計する(つまり余分な算術演算を 行う)方が本当に速いと思いますか? 私の変種では、チェックは最初のマッチで終了しますが、あなたが言った変種では - すべての値を合計してから、その合計をチェックするのです。

しかも、その場合、すべての条件を事前に計算する必要があります。では、ここで言うスピードとは、どのようなものなのでしょうか。最も遅いオプションです。

 
とswitch - caseは良くないのでしょうか?
 

高速化したい場合は、ビット演算を 試すとよいでしょう。

つまり、すべての変数をint型(false=0)にする。次に、ビット単位のA|B|C...>0

 
Avals:

高速化したい場合は、ビット演算を試すとよいでしょう。

つまり、すべての変数をint型(false=0)にする。次に、ビット単位のA|B|C...>0

和算と同じように、すべての条件を事前に計算する必要があります。 また、1つの条件だけで十分なのに、なぜすべての条件を計算する必要があるのでしょう?
 

そして、提案されたバリアントを誰も実行速度でチェックしないのですか?

ここから スクリプトを使用することができます

 
Meat:
一般的には、一番早い選択肢はこれでしょう。

ただし、else result=falseの行は、最初の行と組み合わせた方が、速度に影響しない。一般に、A、B、C、Dに単純な条件(すべての数学関数などを呼び出さず、最小限の演算で済む)が含まれていれば、このような最適化による性能向上はあまり期待できません(もちろん、この構造が何千万回と実行されない限り)。 しかしコードのオーバーロードは大きな意味を持つ場合があるのです。

私は、あるスレッドで、すべては合理的に処理されなければならないと書きました。 なぜか、あなたのコードは、より重要な場所に満ちているようです。 最適化は、本当に大きな性能向上を与えるでしょう。 あなたは、基本アルゴリズムから始めるべきです。 ほとんどの初心者は、TSまたはオープンオーダーに関するすべての条件を毎ティックでチェックするのがばかばかしいです。しかし、ほとんどの場合、例えば、高値や安値がある値に達したときや、新しいバーが現れたときなど、境界条件だけをチェックすれば十分です。 その後で、さらにチェックを行うことができます。

まあ、リソースを大量に消費する計算の他は、これらの計算をDLLに移行することを考える必要がありますね。そうでなければ、クソMQL4で13分間座って待つのは残念なことです(2~3分で同じ結果が出るかもしれませんが)。

if (A) Action();
 else
  if (B) Action();
   else
    if (C) Action();
     else
      if (D) Action();

その方がさらに速いんです。

ある話を思い出した。

"ある会社の役員会で、2つの質問があった。

1.シンクロファソトロンの建設が決定。

2.従業員用自転車駐車場の建設を決定。

最初の課題では、1分間のディスカッションが行われました。

2回目には、2時間以上の討論が行われました。

 
クソMQL4」が嫌な奴は逃げた方がいい、逃げた方が。というのも、彼がここで何をしているのかが不明だからである。