アルゴリズム、解法、性能比較 - ページ 6

 
Alexandr Andreev:

普通にintsの配列でいいじゃん。 なんでTバックなんだよ...。

なぜなら、EAが何回トレードを行うか事前に分からないからです。あらかじめ配列用のメモリを確保する必要があるが、その量がわからない。

そこで、高速かつ短時間で、不要なメモリを消費しない解決策を探すことになったのです。

 
Реter Konow:

そうでもないんです。

...

もう一度言いますが、あなたは私たちが話していることを理解していません。取引番号は、取引システム(MetaTraderまたは取引所)により割り当てられます。取引番号とは、取引のシリアル番号ではなく、正確にはHistoryDealGetTicket 関数で返されるチケットの ことです。だから、これを考慮して、例を修正してください。
 
Alexandr Andreev:

もう一度、文字列の代わりに、チャートの動的 配列を格納するクラスを使用することを想像してみてください - これが高速だと思いますか?

文字列関数の内部構造は知らないが、関数の速度測定では、数千のメジカンの文字列からメジカンを探して返すのに100マイクロ秒を切っている。

私にはとても速く感じられます。高速化は望めない。

 
Реter Konow:

なぜなら、EAが何回トレードを行うか事前に分からないからです。あらかじめ配列用のメモリを確保する必要があるが、その量がわからない。

そのため、高速かつ短時間で、不要なメモリを消費しないソリューションが必要だったのです。

ファストについて 全24000千メジックの抽出速度を測定する。不愉快な思いをすることでしょう。

 
Реter Konow:

完了しました。

あなたの例は、もはや修正することはできません :)

列のサイズが足りないとどうなるのでしょうか?

あなたの例では、32767レコード(トランザクション)があるかもしれないので、最後の書き込みと読み出しのmagicを比較してみてください。


 
Vasiliy Sokolov:
もう一度言いますが、あなたは私たちが話していることを理解していません。取引システム(MetaTraderまたは取引所)により取引番号が割り当てられます。取引番号とは、取引のシリアル番号ではなく、HistoryDealGetTicket 関数で返されるチケットの ことを指します。そこで、この点を考慮し、例を修正します。

問題ないです。明日は、チケットと連動する第2弾を作る予定です。

このバージョンでは、取引にも便利です。

 
Vasiliy Sokolov:

高速 カウントで。24,000,000個のメジクの検索速度を測定する。不愉快な思いをすることになる。

まあ、どんな時でも、メジッチは一人いればいいわけですからね。

メジャーの抽出、注文に関連するあらゆる情報へのアクセス。

なぜ一度に24,000個のメジナを抽出する必要があるのでしょうか?

 

私は一体ここで何をしているんだ!?私は誰と時間を無駄にしているのだろう?もっと強い酒を飲んでこよう。

p.s. そうそう、もう一つ間違いがありますね。3回目の呼び出しでMathRandが 例えば1000番を返して、_3_1000_と書いた場合、序数1000の取引はどのようなメジナになるのでしょうか。
 
Yury Kulikov:

あなたの例は今更直せない :)

列のサイズが足りないとどうなるのでしょうか?

あなたの例では、32767レコード(トランザクション)があるかもしれないので、最後の書き込みと読み出しのmagicを比較してみてください。


行数 制限のご指摘ありがとうございます。

2行目を書き始めることができます。次に3番目と...。:)

 
Реter Konow:

文字列関数の内部実装は知らないが、関数実行時間の測定では、数千のメジナの総文字列からメジナを探して返すのに100マイクロ秒以下であることがわかる。

とても速いと思います。これ以上早くなることはないと思います。


まあ、簡単に言うと、1文字の文字列は、0から255までの何らかのコードを持つ文字で、1バイトの重さなのですが...。で、256個の値を収めるのに十分なメモリが割り当てられているのに、257個はそこに収まらないので、最初のものに切り替わります。

どのページでも、すべての文字が0から255までの数字になっている...。そこで、4バイトの数字10000000を文字列 "10000000 "に変換し、各文字に0から255までのグラフのようにメモリを割り当てる...。合計8バイト。 メモリーセーブはどこにもない。