Ho bisogno di aiuto! Non riesco a risolvere il problema, sto incontrando delle limitazioni hardware - pagina 20
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
komposter, puoi usare una DLL nel tuo EA?
Se è così, potete fare quanto segue:
Impacchettare i dati in un file tabella di intestazione, usando ZLIB
(http://www.zlib.net/)
Funzionerà molto velocemente (sarete sorpresi di quanto velocemente.
La DLL sarà pronta a lavorare in 3 msec. Tutto funzionerà in "tempo reale").
I dati saranno ridotti 5-8 volte e alla fine dello stesso file (imballato)
conterrà una tabella con ID, offset e lunghezza dei dati.
Se avete una quantità molto grande di record nel file sorgente, allora dovete compilare
in una sottotabella (diverse sottotabelle), indicando gli offset nella tabella principale, in modo da non dover
in modo da non dover guardare tutta la tabella, ma solo una piccola parte di essa.
Per esempio: I dati USD sono memorizzati da 0 offset a 1023,
Dati UE da 1024 a 2047 ecc.
Se i dati non sono impacchettati in un file (sarà enorme), ci sarà
un'altra (minuscola) sottotabella, in cui il packer indicherà il numero di file.
E quando la DLL carica i file, creerà una sottotabella comune dalle sottotabelle di
di tutti i file. Meglio ancora, tutti gli offset sono memorizzati nel primo file, e se
si "esce" da 1 file, i dati vengono presi dal secondo file, ecc.
Ho dimenticato...
Se accettate il mio consiglio, vi consiglio di mettere in valigia il vostro
dati di testo con la funzione di impacchettamento di stringhe Zlib (non dati binari, funziona più velocemente).
Credo che la funzione si chiami ZCompressString...
Lo zapping, così come la crittografia, possono già essere standard:
Metodi di crittografia dei dati
Per specificare il metodo di conversione dei dati (crittografia e calcolo dell'hash), l'enumerazione ENUM_CRYPT_METHOD è usata nelle funzioni CryptEncode() e CryptDecode().
ENUM_CRYPT_METHOD
Costante
Descrizione
CRYPT_BASE64
Crittografia BASE64 (transcodifica)
CRYPT_AES128
Crittografia AES con chiave a 128 bit (16 byte)
CRYPT_AES256
Crittografia AES a 256 bit (32 byte)
CRYPT_DES
Crittografia DES con chiave di 56 bit (7 byte)
CRYPT_HASH_SHA1
Calcolare HASH SHA1
CRYPT_HASH_SHA256
Calcolare HASH SHA256
CRYPT_HASH_MD5
Calcolo HASH MD5
CRYPT_ARCH_ZIP
Archiviazione ZIP
Lo zapping, così come la crittografia, possono già essere standard:
Metodi di crittografia dei dati
Per specificare il metodo di conversione dei dati (crittografia e calcolo dell'hash), l'enumerazione ENUM_CRYPT_METHOD è usata nelle funzioni CryptEncode() e CryptDecode().
ENUM_CRYPT_METHOD
Costante
Descrizione
CRYPT_BASE64
Crittografia BASE64 (transcodifica)
CRYPT_AES128
Crittografia AES con chiave a 128 bit (16 byte)
CRYPT_AES256
Crittografia AES a 256 bit (32 byte)
CRYPT_DES
Crittografia DES con chiave di 56 bit (7 byte)
CRYPT_HASH_SHA1
Calcolare HASH SHA1
CRYPT_HASH_SHA256
Calcolare HASH SHA256
CRYPT_HASH_MD5
Calcolo HASH MD5
CRYPT_ARCH_ZIP
Archiviazione ZIP
La questione non è la crittografia, ma come accedere rapidamente ai dati.
Lo scopo dell'archiviazione è di ridurre la dimensione dei dati e permettere il trasferimento veloce degli offset
non il file principale (20GB), ma uno 5-8 volte più piccolo.
Ma non basta impacchettare, bisogna anche avere un meccanismo di accesso veloce ai dati.
P/S Zlib ha funzioni per la compressione e decompressione veloce delle stringhe.
Ho fatto notare che non è più necessario avere dll di terzi per impacchettare o criptare i dati. Al contrario del vostro metodo DLL.
Non ho parlato di risolvere il problema del topstarter.
Ho sottolineato che non è più necessario avere dll di terze parti per impacchettare o criptare i dati. Al contrario del vostro metodo DLL.
Non ho parlato di una soluzione al problema del topicstarter.
Una DLL non è uno spacchettatore di dati, ma un meccanismo per estrarre rapidamente i dati da
file impacchettato secondo un certo schema.
Bene, tutto questo è ora facilmente realizzabile utilizzando gli strumenti linguistici. La compressione è disponibile dalla norma.
Grande, ora il topicstarter probabilmente risolverà il suo problema.
Non ho mai lavorato con i file in MQL5, vedrò se è possibile aprire
Non ho mai lavorato con i file in MQL5.
Sì, lo è :)
Tutto funziona ed è veloce. Ho descritto i metodi di cui sopra per rendere le operazioni sui file più efficienti nella nostra implementazione.
Non sto sottovalutando le abilità e le capacità del terminale, ma
quando avevo bisogno di estrarre dati da un file di 1.21Gb, con 21.345.728(!) linee, un paio di anni fa,
http://ftp.micex.com/pub/info/historical_data/Securities_market/OrderBook20130206.rar
dati della forma:
NO, SECCODE, BUYSELL, TEMPO, ORDERNO, AZIONE, PREZZO, VOLUME, TRADENO, TRADEPRICE
21345728,USD000UTSTOM,B,235000002,3568,0,29.6095,300000,,
Allora con il metodo che ho indicato, il tempo di ricerca era di 35-45 MICROSECONDI,
È vero che il file è stato preparato per più di 2 giorni :(
P / S Non si tratta di cosa usare (terminale o DLL), ma di come preparare i dati.
E il fatto che ci siano nuove funzionalità nel terminale è molto gradito!
Non sto sottovalutando le capacità del terminale, ma
quando avevo bisogno di estrarre dati da un file di 1,21 GB un paio di anni fa, con 21.345.728(!) linee,
http://ftp.micex.com/pub/info/historical_data/Securities_market/OrderBook20130206.rar
dati della forma:
NO, SECCODE, BUYSELL, TEMPO, ORDERNO, AZIONE, PREZZO, VOLUME, TRADENO, TRADEPRICE
21345728,USD000UTSTOM,B,235000002,3568,0,29.6095,300000,,
Allora con il metodo che ho indicato, il tempo di ricerca era di 35-45 MICROSECONDI,
È vero che il file è stato preparato per più di 2 giorni :(