エラー、バグ、質問 - ページ 2668

[fxsaber]

Sergey Dzyublik:

問題は、メモリを確保して配列の要素を 1つずつ作成すると、一度に作成 するよりも何倍も時間がかかることです。

コードでは気がつかなかった。説明すると、ifトリガーは1つだけで、サイズが変化していなければ終了するようになっています。

[Sergey Dzyublik]

fxsaber:

コードでは気がつかなかった。説明すると、ifトリガーは1つだけで、サイズが変化していなければ終了するようになっています。

上記コードの説明#2666

test1では、最初の呼び出しですべての要素を一度に作成し、ArrayResizeの残りの呼び出しは「アイドル」状態になります。
ArrayResize 呼び出しの総数 == array_size:

      T class_array[];
      for(int i = 1; i <= array_size; i++){
         ArrayResize(class_array, array_size);
      }

test2 では、1 つの要素を作成し、別の array_size-1 要素のための領域を確保します。ArrayResize の残りのコールは、以前に確保したメモリから配列に +1 の要素を作成するために行われます。
ArrayResize == array_size を呼び出した回数の合計です。

      T class_array[];
      ArrayResize(class_array, 1, array_size - 1);
      for(int i = 2; i <= array_size; i++){
         ArrayResize(class_array, i);
      }

* 元のコードに誤りがありました（+- 1要素の差）。コードが更新されました。
なぜ test2 は test1 よりも構造体で 7 倍、クラスと int で 2 倍も遅いのでしょうか？

[Alain Verleyen]

Sergey Dzyublik :

私の方では、比較対象は想定内のものでした。
配列に入れる要素の数がわかっているので、一度に全部作るのではなく、未作成の要素用にメモリを確保しています。
問題は、メモリを確保して配列項目を 1つずつ作成すると、一度に作成するよりも何倍も時間がかかることです。
つまり、構造物の場合は7倍も遅くなるわけです。
また、classとintデータ型では2倍遅くなる。

これは非常に大きな違いであり、開発者が望めば解消できることだと思います。

この場合、オーバーヘッドが低ければいいというのは賛成です。

でも、問題はむしろ比較の仕方だと思うんです。test1のループは、おそらくコンパイラによって最適化され、削除され、おそらく次もそうでしょう。

 for ( ulong ii= 0 ;ii<count&&! _StopFlag ;ii++)

プロファイラを試してみても、わずかな違いしかわからないでしょう。

[Alain Verleyen]

プロファイラによる コンパイラの最適化なし。

[fxsaber]

Sergey Dzyublik:

疑問が残ります。なぜ test2 は test1 よりも構造体で 7 倍、クラスと int で 2 倍も遅いのでしょうか？

デフォルトのコンストラクタです。

[Sergey Dzyublik]

Alain Verleyen:

test1のループは、おそらくコンパイラによって最適化され、削除されたものだと思われます

上記のコード#2666を Debugモードで実行すると、ユーザーコードの最適化ではなく、ArrayResize関数の働きによって速度低下が起こるため、先ほどと同様の結果が得られるでしょう。
デバッグモードは最適化なしで実行されます。コードに書かれていることが実行され、実行されたものは、ユーザーブレークポイントのためのnop-typesが命令の間に挿入されるだけです。

[Aleksei Skrypnev]

新サービスのSMSでデモ口座開設の確認メールが届かない。

https://www.mql5.com/ru/forum/334179#comment_1529250

[Alain Verleyen]

Sergey Dzyublik :

上記のコード#2666を Debugモードで実行すると、ArrayResize関数の動作にラグがあり、ユーザーコードの最適化には関係ないため、先ほどと同様の結果が得られると思います。
デバッグモードでは、最適化を行わず、コードに書かれていることが実行され、ユーザーブレークポイントのために命令の間にnopsが挿入されるだけです。

投稿番号26674に あるように、ArrayResize()では問題ないのですが、比較テストのみです。私が何かを見逃していなければ。

[Sergey Dzyublik]

Alain Verleyen:
投稿番号26674に あるように、ArrayResize()では問題なく、比較テストのみで問題ありません。私が何かを見逃していなければ。

この問題は、実際のプロジェクトで、vector<T>::push_backアルゴリズムのボトルネックを探しているときに検出されました。
この問題は、ReleaseとDebugの両方のコンパイルにおいて、予約メモリがある場合にArrayResizeの実行が遅くなることの一部として現れます。

プロファイリングで何も検出されなかったから大丈夫と言い張るのか。
得られた結果を気にする人はいない。
しかし、プロファイリングで明らかな問題がなくても、100%のユーザーが使用するReleaseコンパイルやDebugコンパイルでは、その問題がキャンセルされるわけではありません。

[Alain Verleyen]

Sergey Dzyublik :

実際のプロジェクトで、vector<T>::push_backアルゴリズムのボトルネックを探しているときに、この問題が検出されました。
Release版、Debug版ともに予約メモリがある場合、ArrayResizeの実行が遅くなる問題が発生します。

プロファイリングで何も検出されなかったから大丈夫と言い張るのか。
得られた結果を気にする人はいない。
しかし、プロファイリングで明らかな問題がなくても、100%のユーザーが使用するReleaseコンパイルやDebugコンパイルでは、その問題がキャンセルされるわけではありません。

提供されたテストコードについてしかお話できませんが。

いずれにせよ、開発者の声を聞いてみよう。そうかもしれませんね。