助けてください問題が解決できない、ハードウェアの限界にぶつかる - ページ 20

[Mikhail Filimonov]

komposterさん、EAでDLLは使えるんですか？

その場合は、次のようにしてください。

ZLIBを使用して、データをヘッダーテーブルファイルにパッキングします。

(http://www.zlib.net/)

とても早く効くようになります（驚くほど早いです。

DLLは3msecで動作可能な状態になります。すべてが "リアルタイム "で動作します）。

データは5～8回に縮小され、同じファイルの最後に（パックされます）

は、ID、オフセット、データ長を含むテーブルを含みます。

ソースファイルに非常に多くのレコードがある場合、コンパイルする必要があります。

をサブテーブル（複数のサブテーブル）にして、メインテーブルのオフセットを示すことで、不要な

テーブル全体を見ずに、その一部分だけを見ることができるように。

例えば、こんな感じです。USDデータは、0オフセットから1023まで格納されています。

EUデータ 1024から2047まで など

データが1つのファイルにまとまらない（巨大になる）場合、そこには

もうひとつの (小さな) サブテーブルがあり、パッカーはそこにファイル番号を表示します。

そして、DLLがファイルを読み込むと、サブテーブルから共通のサブテーブルを

全ファイルのさらに良いことに、すべてのオフセットが最初の ファイルに格納されており、もし

1つのファイルの外に出て、2番目のファイルからデータを取得する、など。

忘れてた...

私のアドバイスに従うなら、荷造りすることをお勧めします。

テキストデータをZlibの文字列パッキング機能（バイナリデータではなく、より高速に動作する）を使用しています。

ZCompressStringという関数があると思うのですが...。

[Renat Fatkhullin]

暗号化だけでなく、ジッピングもすでに標準装備できる。

• https://www.mql5.com/ru/docs/common/cryptencode
  
• https://www.mql5.com/ru/docs/common/cryptdecode

データ暗号化方式

データ変換（暗号化、ハッシュ計算）の方法を指定するために、関数CryptEncode(),CryptDecode()ではENUM_CRYPT_METHOD列挙を使用します。

enum_crypt_method

定数	商品説明
CRYPT_BASE64	BASE64暗号化(トランスコード)
CRYPT_AES128	128ビット鍵によるAES暗号化（16バイト）
CRYPT_AES256	256ビット（32バイト）AES暗号化方式
CRYPT_DES	鍵56ビット（7バイト）のDES暗号化
crypt_hash_sha1	HASH SHA1 を計算する
crypt_hash_sha256	HASH SHA256を計算する
CRYPT_HASH_MD5	HASH計算 MD5
CRYPT_ARCH_ZIP	ZIP アーカイブ

[Mikhail Filimonov]

Renat:

暗号化だけでなく、ジッピングもすでに標準装備できる。

• https://www.mql5.com/ru/docs/common/cryptencode
  
• https://www.mql5.com/ru/docs/common/cryptdecode

データ暗号化方式

データ変換（暗号化、ハッシュ計算）の方法を指定するために、関数CryptEncode(),CryptDecode()ではENUM_CRYPT_METHOD列挙を使用します。

enum_crypt_method

定数	商品説明
CRYPT_BASE64	BASE64暗号化(トランスコード)
CRYPT_AES128	128ビット鍵によるAES暗号化（16バイト）
CRYPT_AES256	256ビット（32バイト）AES暗号化方式
CRYPT_DES	鍵56ビット（7バイト）のDES暗号化
crypt_hash_sha1	HASH SHA1 を計算する
crypt_hash_sha256	HASH SHA256を計算する
CRYPT_HASH_MD5	HASH計算 MD5
CRYPT_ARCH_ZIP	ZIP アーカイブ

問題は暗号化ではなく、いかに素早くデータにアクセスするかということです。

アーカイブの目的は、データサイズを小さくし、オフセットの高速転送を可能にすることである

メイン（20GB）のファイルではなく、5～8倍程度の小さいファイルです。

しかし、パックするだけでは不十分で、データに素早くアクセスできる仕組みも必要です。

P/S Zlibは、文字列の圧縮・伸張を高速に行うための機能を備えています。

[Renat Fatkhullin]

私は、データを パックしたり暗号 化するためのサードパーティのDLLが不要になったことを指摘しました。あなたのDLL方式とは対照的です。

トップスターターの問題を解決する話はしていない。

[Mikhail Filimonov]

Renat:

サードパーティ製のDLLでパックや暗号化する必要がなくなったことを指摘した。あなたのDLL方式とは対照的です。

トピックスターターの問題を解決するとは一言も言っていない。

DLLはデータを解凍するものではなく、データを素早く抽出するための仕組みで

特定のスキームに従ってパッキングされたファイル。

[Renat Fatkhullin]

そのすべてが、言語を使って簡単にできるようになったのです。標準で圧縮が可能です。

[Mikhail Filimonov]

Renat:
しかし、このようなことは、言語ツールを使って簡単にできるようになりました。圧縮は標準から可能です。

素晴らしい！これでトピックスターターが彼の問題を解決してくれるでしょう。

MQL5でファイルを扱ったことがないので、開くことが可能かどうか見てみます。

MQL5でファイルを扱ったことはない。

はい、そうです :)

bool  FileSeek(
   int                  file_handle,     // handle файла
   long                 offset,          // в байтах
   ENUM_FILE_POSITION   origin           // позиция для отсчета
   );

Будем надеятся, что терминал работает так же быстро, как и нативная DLL

[Renat Fatkhullin]

すべてが機能し、速い。以上、本実装におけるファイル操作の効率化のための方法を説明しました。

[Mikhail Filimonov]

Renat:
すべてが機能し、速い。以上、今回の実装でファイル操作を効率化するための方法を説明しました。

端末の能力や性能を控えめに言っているわけではありませんが

数年前、1.21Gbのファイルから21,345,728（！）行のデータを抽出する必要があったとき。

http://ftp.micex.com/pub/info/historical_data/Securities_market/OrderBook20130206.rar

形式のデータです。

No、証券コード、買い、売り、時間、注文番号、アクション、価格、ボリューム、トラデノ、トラデプレート

21345728,USD000UTSTOM,B,235000002,3568,0,29.6095,300000,,

すると、私が示した方法で、検索時間は35〜45マイクロ秒でした。

確かに、2日以上前からファイルを用意していたのは事実です :(

P / S 何を使うか（ターミナルかDLLか）ではなく、データをどう用意するかが重要です。

また、端末に新機能が搭載されたことは、とても喜ばしいことです

[Eugeniy Lugovoy]

Mikalas:

端末の能力を過小評価しているわけではありませんが

数年前に1.21GBのファイルからデータを抽出する必要があったとき、21,345,728(!)行もあったんです。

http://ftp.micex.com/pub/info/historical_data/Securities_market/OrderBook20130206.rar

形式のデータです。

No、証券コード、買い、売り、時間、注文番号、アクション、価格、ボリューム、トラデノ、トラデプレート

21345728,USD000UTSTOM,B,235000002,3568,0,29.6095,300000,,

すると、私が示した方法で、検索時間は35〜45マイクロ秒でした。

2日以上前から準備していたというのが本当のところです :(

ミリ秒くらいかな？WindowsベースのOSでマイクロ秒単位の計測は、どうしてもできない...。