voracità della memoria RAM di MT5, problemi con la lettura/scrittura di file di grandi dimensioni - pagina 7

 
Risulta che il mio terminale senza lo script sta consumando 820mb, quindi il binario sta consumando 180 megabyte, che è apparentemente OK, dati i due array riempiti.
 
L'argomento non è formulato correttamente.

La memoria non è consumata dal terminale, ma da un programma specifico con una specifica implementazione. In questo caso, il programma MQL sta memorizzando i dati in modo errato e inefficiente.
 
Aleksey Vyazmikin:

Mi puoi dire cosa sistemare in esso?

Beh, va bene, si legge prima l'array, ma dopo aver letto il file, bisogna chiuderlo.

e poi scrivere allo stesso modo, non attraverso la vostra biblioteca.

 
Renat Fatkhullin:
L'argomento non è formulato correttamente.

La memoria non è consumata dal terminale, ma da un programma specifico con una specifica implementazione. In questo caso, il programma MQL sta memorizzando i dati in modo errato e inefficiente.

L'argomento è stato formulato nel momento in cui il problema è sorto, quando non c'era una comprensione definitiva delle cause. Ho proceduto dal fatto che ho una classe che è stata creata con il coinvolgimento di un dipendente di MQ, il che significa che non avevo motivo di dubitare della sua correttezza.

Se il programma non memorizza i dati in modo corretto ed efficiente, potete dirmi come memorizzarli in modo corretto ed efficiente? Cosa dovrei cambiare nella classe per fargli consumare meno memoria?

In generale, sarebbe molto bello se il terminale fosse fornito con una classe simile per lavorare con tabelle basate su CSV.

 
Maxim Dmitrievsky:

Va bene leggere prima l'array, ma dopo aver letto il file bisogna chiuderlo

e scrivere allo stesso modo, non attraverso la vostra biblioteca.

Lo chiuderò, grazie.

Devo scrivere in due varianti, perché il formato CSV mi aiuta a vedere davvero cosa sta succedendo negli array - ahimè, faccio degli errori e quindi preferisco ricontrollare i calcoli in excel durante il debug del codice, piuttosto che trarre conclusioni sbagliate in seguito.

 
Vladimir:

Cosa avete imparato dalla documentazione sul terzo parametro che è utile in questo caso, quando si risolve il problema di sollevare in memoria .csv creati in diversi programmi e di dimensioni arbitrarie?

Sentitevi liberi di suggerire una modifica migliore, non binaria, che aumenta la velocità di riallocazione della memoria (riducendo il numero di chiamate ArrayResize) più di una ricerca binaria...

Lezione gratuita per principianti:

Il terzo parametro ArrayResize specifica la dimensione effettiva dell'array, un multiplo di questo numero.

ArrayResize(arr, 5, 1000) - prenderà 1000 elementi in memoria.

ArrayResize(arr, 1005, 1000) - occuperà 2000 elementi in memoria.

Ecco perché non c'è un'allocazione permanente della memoria.

 
Aleksey Vyazmikin:

L'argomento è stato formulato nel momento in cui il problema è sorto, quando non c'era una comprensione definitiva delle cause. Il mio presupposto era che ho una classe che è stata creata con l'input di un dipendente di MQ, il che significa che non avevo motivo di dubitare che stesse lavorando correttamente.

Se il programma non memorizza i dati in modo corretto ed efficiente, potete dirmi come memorizzarli in modo corretto ed efficiente? Cosa dovrei cambiare nella classe per fargli consumare meno memoria?

In generale, sarebbe molto bello se il terminale fosse fornito con una classe simile per lavorare con tabelle basate su CSV.

Il problema non è nella classe, ma nell'uso di questa classe.

Infatti, la lettura da CSV è già implementata a livello di FileOpen con il flag FILE_CSV.

Non c'è bisogno di un'intera classe separata per questo.

 
Roffild:

Una lezione gratuita per i principianti:

Il terzo parametro ArrayResize imposta la dimensione effettiva dell'array a un multiplo di questo numero.

ArrayResize(arr, 5, 1000) - occuperà 1000 elementi in memoria.

ArrayResize(arr, 1005, 1000) - occuperà la memoria di 2000 elementi.

Ecco perché non c'è un'allocazione permanente della memoria.

Vladimir, a differenza di te, è riuscito ad analizzare il codice e a trovare un modo per velocizzarlo. E lei si sta posizionando qui come un teorico che non può trattare con il codice di qualcun altro. Tutte queste conclusioni - cosa ti danno, forse puoi dimostrare che l'aggiunta di parametri aggiuntivi velocizzerà il codice o ridurrà il consumo di memoria?


Roffild:

Il problema non è nella classe, ma in come la classe viene usata.

Infatti, la lettura da CSV è già implementata a livello di FileOpen con il flag FILE_CSV.

Non c'è bisogno di un'intera classe separata per questo.

Se non capite a cosa serve, perché prendete decisioni per gli altri? Sto dicendo che bisogna renderlo conveniente per le persone, è per questo che le classi sono scritte.

 
Aleksey Vyazmikin:

Vladimir, a differenza di te, è stato in grado di analizzare il codice e trovare un modo per velocizzarlo. E lei si sta posizionando qui come un teorico che non può lavorare con il codice degli altri. Tutte queste conclusioni - cosa ti danno, forse puoi dimostrare che l'aggiunta di parametri aggiuntivi velocizza il lavoro o riduce il consumo di memoria?

In realtà Vladimir non potrebbe rendere la classe più veloce modificandola. La classe è stata creata da un "dipendente di MQ" e un utente che non ha letto la documentazione è riuscito a migliorare la classe?

Aleksey Vyazmikin:

Se non capite a cosa serve, perché decidete per gli altri? Io dico che bisogna renderlo conveniente per le persone, è per questo che le classi sono scritte.

Quindi, per usare le funzioni standard, dovete avvolgerle in classi?

Forse dovresti leggere la documentazione su FILE_CSV, invece di usare un'intera classe separata?

Ci sono già state altre soluzioni pronte postate qui che sono state ignorate.

La mia soluzione per scrivere su CSV senza limiti al numero di colonne è nella mia libreria. Anche i principi di OOP (non credo che tu conosca questo metodo di programmazione) sono rispettati. Ma non lo raccomando.

È improbabile che la soluzione giusta appaia qui gratuitamente...

 
Roffild:

In realtà, non c'è modo che Vladimir abbia potuto accelerare la classe con le sue modifiche. La classe è stata creata da un "dipendente di MQ" e l'utente, che non ha letto la documentazione, è riuscito a migliorare la classe?

Hai controllato e non è stata rilevata alcuna accelerazione? O stai dicendo che sto ingannando tutti qui?

Roffild:

Quindi, per usare le funzioni standard, dovete avvolgerle in classi?

Forse dovresti leggere la documentazione su FILE_CSV invece di usare un'intera classe separata?

Ci sono già state altre soluzioni pronte postate qui che sono state ignorate.

La mia soluzione per scrivere su CSV senza limiti al numero di colonne è nella mia libreria. Anche i principi di OOP (non credo che tu conosca questo metodo di programmazione) sono rispettati. Ma non lo raccomando.

Una soluzione gratuita è improbabile che appaia qui...

Hai letto attentamente questo thread? Avete visto la mia risposta alla soluzione pronta sotto forma di funzione? Avete un'altra soluzione? Naturalmente, non so cosa sia OOP, un lettore attento di questo thread l'avrebbe notato subito...

A proposito di redditività/libertà - è ridicolo, stavo solo dimostrando che le soluzioni a pagamento non rendono una soluzione migliore di una gratuita, mentre tu stai parlando di nuovo di soldi...