MT5とスピードの関係 - ページ 91 1...8485868788899091929394 新しいコメント fxsaber 2021.03.17 12:34 #901 Anton: ObjectGetIntergerのブレーキは当たり前? Renat Fatkhullin 2021.03.17 13:05 #902 fxsaber:ObjectGetIntergerのブレーキは当たり前? Getメソッドはすでにsynchronousなので、待ちます。オブジェクトの操作は、オブジェクトへの直接アクセスではなく、特別なコマンドキューを通して行われます。 ちなみに、SetメソッドとGetメソッドを混在させないことを強く推奨します。writeを複数形にしてからreadを複数形にするとよいでしょう。あるいはその逆もしかり。 fxsaber 2021.03.17 13:33 #903 Renat Fatkhullin:Getメソッドはすでにsynchronousなので、待機しています。オブジェクトは、オブジェクトへの直接アクセスではなく、特別なコマンドキューで処理 されます。ちなみに、SetメソッドとGetメソッドを混在させることは推奨されません。setと書いてからread setと 読むとよい。あるいはその逆もしかり。 残念ながら問題があるんです。上記のコードで表示されます。 分かりやすい説明ありがとうございます。 fxsaber 2021.03.29 14:47 #904 ある場面で邪魔になった。 実アカウントで 実行した結果。 2021.03.29 17:18:55.280 TradesID_Example (EURUSD,M1) HistoryDealsTotal() = 99663 2021.03.29 17:18:55.280 TradesID_Example (EURUSD,M1) HistoryOrdersTotal() = 174307 2021.03.29 17:24:15.862 TradesID_Example (EURUSD,M1) GetSumByPositionsID(PositionsID,GetSumByPositionID) = 29906412.60837016 2021.03.29 17:24:15.862 TradesID_Example (EURUSD,M1) Alert: Bench_Stack = 0, 1 <= Time[GetSumByPositionsID(PositionsID,GetSumByPositionID))] = 320581370 mcs. 2021.03.29 17:24:16.057 TradesID_Example (EURUSD,M1) GetSumByPositionsID(PositionsID,GetSumByPositionID2) = 29906412.60837016 2021.03.29 17:24:16.057 TradesID_Example (EURUSD,M1) Alert: Bench_Stack = 0, 1 <= Time[GetSumByPositionsID(PositionsID,GetSumByPositionID2))] = 195526 mcs. 2021.03.29 17:24:16.170 TradesID_Example (EURUSD,M1) GetSumByPositionsID(PositionsID,GetSumByPositionID2) = 29906412.60837016 2021.03.29 17:24:16.170 TradesID_Example (EURUSD,M1) Alert: Bench_Stack = 0, 1 <= Time[GetSumByPositionsID(PositionsID,GetSumByPositionID2))] = 112839 mcs. 通常の実装に比べ、約2500倍の高速化を実現。この方法によってのみ、合理的な時間でいくつかの計算を行うことができます。 Rorschach 2021.04.07 10:20 #905 ターミナルに強制的にメモリを確保させるには、次のスクリプトを実行します。 void OnStart() { short arr[]; ArrayResize(arr,INT_MAX); ArrayInitialize(arr,0); Print(ArraySize(arr)); Sleep(5000); } アレイサイズを RAMサイズに合わせる fxsaber 2021.04.07 10:31 #906 Rorschach:ターミナルに強制的にメモリを確保させるには、次のスクリプトを実行します。アレイサイズを RAMサイズに合わせる 何を考えているのか? traveller00 2021.04.07 10:42 #907 fxsaber:何を考えているのか? どうやら、端末をメモリ不足の 状態にして、それを解放するための内部機構が働くかどうかを確認するようです。 Rorschach 2021.04.07 10:55 #908 traveller00:どうやら、端末をメモリ不足の 状態にすると、内部でメモリ解放の仕組みが働くようです。 はい、端末がメモリ不足になり、キャッシュされたデータのリセットを開始します Vasiliy Pushkaryov 2021.07.29 13:59 #909 規格外の事態が発生しました。Expert Advisorは、インジケータのシグナルに基づいてスクリーンショットを撮影し、フィルターが通過した場合、ポジションをオープン/クローズするコマンドを出します。 スクリーンショット名には、CHFJPY_d29_h10_m24_s17の ように、日、時、秒の時刻が含まれます。時刻はTimeCurrent()関数から取得する。 ターミナルには28個のExpert Advisorのインスタンスが動作しています。ある時から44分間、端末がフリーズしたような状態になり、10時27分に再び正常に動作するようになりました。以下は、端末のログそのものの部分です。 接続の中断は確認できない。EURUSDの10:27の最初のエントリーは、取引履歴の10:14のslの終値です。 以下は、EAからのログの一部です。上の赤枠で示したように、ログの記録時刻とスクリーンショット名にもあるTimeCurrent()の時刻はほぼ同じです。 そして、下のフレームでは、その差は30分。 CHFJPYのシンボルでは、10時12分にオープニングシグナルを含む1つのスクリーンショットが形成され、10時24分にシグナルを含む2つ目のスクリーンショットが形成されました。しかし、10時27分の1分間に開店・閉店と新規開店が起こった。 1) TimeCurrent()が動作し、実際のサーバー時刻を取得すると、Expert Advisorはインジケータから正しい信号を受信します。 2)ログが書き込まれたのは10時27分です。スクリーンショットは10:27にハードディスクのFilesフォルダに書き込まれ、新しい注文(古いシグナルに基づく)は10:27にオープンされました。 もしかしたら、どなたか遭遇したことがあるかもしれませんが、このようなしゃっくりやスローダウンの原因は何でしょうか?どのような機能で検出すればよいか教えてください。この状況は、4月以降も何度か繰り返されている。 fxsaber 2021.07.29 14:13 #910 Vasiliy Pushkaryov:どのような関数で原因をつかめばよいか教えてください。 TimeLocalとTimeCurrentの 不一致を監視する。 1...8485868788899091929394 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
ObjectGetIntergerのブレーキは当たり前?
ObjectGetIntergerのブレーキは当たり前?
Getメソッドはすでにsynchronousなので、待ちます。オブジェクトの操作は、オブジェクトへの直接アクセスではなく、特別なコマンドキューを通して行われます。
ちなみに、SetメソッドとGetメソッドを混在させないことを強く推奨します。writeを複数形にしてからreadを複数形にするとよいでしょう。あるいはその逆もしかり。
Getメソッドはすでにsynchronousなので、待機しています。オブジェクトは、オブジェクトへの直接アクセスではなく、特別なコマンドキューで処理 されます。
ちなみに、SetメソッドとGetメソッドを混在させることは推奨されません。setと書いてからread setと 読むとよい。あるいはその逆もしかり。
残念ながら問題があるんです。上記のコードで表示されます。
分かりやすい説明ありがとうございます。
実アカウントで 実行した結果。
通常の実装に比べ、約2500倍の高速化を実現。この方法によってのみ、合理的な時間でいくつかの計算を行うことができます。
ターミナルに強制的にメモリを確保させるには、次のスクリプトを実行します。
アレイサイズを RAMサイズに合わせる
ターミナルに強制的にメモリを確保させるには、次のスクリプトを実行します。
アレイサイズを RAMサイズに合わせる
何を考えているのか?
何を考えているのか?
どうやら、端末をメモリ不足の 状態にして、それを解放するための内部機構が働くかどうかを確認するようです。
どうやら、端末をメモリ不足の 状態にすると、内部でメモリ解放の仕組みが働くようです。
はい、端末がメモリ不足になり、キャッシュされたデータのリセットを開始します
規格外の事態が発生しました。Expert Advisorは、インジケータのシグナルに基づいてスクリーンショットを撮影し、フィルターが通過した場合、ポジションをオープン/クローズするコマンドを出します。
スクリーンショット名には、CHFJPY_d29_h10_m24_s17の ように、日、時、秒の時刻が含まれます。時刻はTimeCurrent()関数から取得する。
ターミナルには28個のExpert Advisorのインスタンスが動作しています。ある時から44分間、端末がフリーズしたような状態になり、10時27分に再び正常に動作するようになりました。以下は、端末のログそのものの部分です。
接続の中断は確認できない。EURUSDの10:27の最初のエントリーは、取引履歴の10:14のslの終値です。
以下は、EAからのログの一部です。上の赤枠で示したように、ログの記録時刻とスクリーンショット名にもあるTimeCurrent()の時刻はほぼ同じです。
そして、下のフレームでは、その差は30分。
CHFJPYのシンボルでは、10時12分にオープニングシグナルを含む1つのスクリーンショットが形成され、10時24分にシグナルを含む2つ目のスクリーンショットが形成されました。しかし、10時27分の1分間に開店・閉店と新規開店が起こった。
1) TimeCurrent()が動作し、実際のサーバー時刻を取得すると、Expert Advisorはインジケータから正しい信号を受信します。
2)ログが書き込まれたのは10時27分です。スクリーンショットは10:27にハードディスクのFilesフォルダに書き込まれ、新しい注文(古いシグナルに基づく)は10:27にオープンされました。
もしかしたら、どなたか遭遇したことがあるかもしれませんが、このようなしゃっくりやスローダウンの原因は何でしょうか?どのような機能で検出すればよいか教えてください。この状況は、4月以降も何度か繰り返されている。
どのような関数で原因をつかめばよいか教えてください。
TimeLocalとTimeCurrentの 不一致を監視する。