Voracité de la mémoire RAM de MT5, problèmes de lecture/écriture de gros fichiers - page 2
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
J'ai déjà rencontré ce problème. J'ai fait beaucoup de réparations. Je ne me souviens pas de tout - c'était une tâche ponctuelle,
mais essayez de définirArrayResize(arrRead_01,arrSize); le 3ème paramètre ici
intreserve_size=0// valeur de la taille de la réserve (excès )
et expérimenter.
Merci, mais tous les décalages et la consommation de mémoire, à en juger par mes expériences, se produisent dans la classe pour lire les informations du fichier. On peut peut-être y remédier ?
À en juger par la vitesse de réaffectation de la mémoire, les tableaux de chaînes de caractères sont stockés comme des tableaux d'objets, et non comme des pointeurs vers eux, d'où les freins. Nous avons besoin que les développeurs clarifient cette question, la solution en dépend.
Ensuite, l'analyseur syntaxique crée un tableau local de cellules à partir de la chaîne de caractères, puis les copie dans la mémoire allouée, ce qui constitue une béquille inutile, et de taille.
S'il s'agit d'un tableau d'objets - alors, en fonction de la fréquence et du nombre de mises à jour des cellules du problème, il serait probablement plus économique en temps de ne pas analyser le fichier au chargement, et de stocker le fichier xw comme un tableau de lignes de fichier et de mettre à jour les données à la volée (c'est-à-dire d'analyser la chaîne à chaque accès à la cellule). Dans tous les cas, l'analyseur doit être réécrit, il est extrêmement inefficace, ne supporte pas les cellules citées et ne convient que pour l'importation de tableaux numériques.
À en juger par la vitesse de réaffectation de la mémoire, les tableaux de chaînes de caractères sont stockés comme des tableaux d'objets, et non comme des pointeurs vers eux, d'où les freins. Nous avons besoin de développeurs pour clarifier cette question, la solution en dépend.
Essayons d'appeler le développeur,@Renat Fatkhullin- pouvez-vous clarifier la situation ?
Ensuite, l'analyseur syntaxique crée un tableau local de cellules à partir d'une chaîne de caractères, puis les copie dans la mémoire allouée - une béquille inutile, et de taille.
Comment pouvons-nous nous en débarrasser ?
S'il s'agit de tableaux d'objets, en fonction de la fréquence et du nombre de mises à jour des cellules du problème, il serait probablement moins coûteux en temps de ne pas analyser le fichier au chargement, et de stocker le fichier xw comme un tableau de lignes de fichier et de mettre à jour les données à la volée (c'est-à-dire analyser la chaîne à chaque accès à la cellule). Dans tous les cas, l'analyseur doit être réécrit, il est extrêmement inefficace, ne supporte pas les cellules citées et n'est bon que pour l'importation de tableaux numériques.
"Tableau de lignes de fichiers" - qu'entendez-vous par là ? S'il s'agit simplement de créer un tableau pour contenir toutes les chaînes de caractères, alors si je comprends bien, la longueur de la chaîne est limitée à un nombre de caractères, non ?
La classe de lecture a été écrite par un employé de MQ, j'ai trouvé que tout y était intelligemment écrit.
Le parser lit le texte correctement, je ne suis pas d'accord avec vous ici - le script précédemment joint le confirme.
Essayons d'appeler le développeur,@Renat Fatkhullin- pouvez-vous clarifier la situation ?
Comment s'en débarrasser ?
"Tableau de chaînes de fichiers" - que voulez-vous dire ? S'il s'agit simplement de créer un tableau où toutes les chaînes seront écrites, alors, si je comprends bien, la longueur de la chaîne est limitée à un nombre de caractères, non ?
La classe de lecture a été écrite par un employé de MQ, j'ai trouvé que tout y était intelligemment écrit.
Le parser lit correctement le texte, je ne suis pas d'accord avec vous - le script précédemment joint le confirme.
Il lit correctement les fichiers où il n'y a pas de chaînes entre guillemets, à l'intérieur desquelles il y a un caractère de délimitation. Essayez de lire 60 ;" "sample;string"" par elle. La sortie devrait contenir 2 cellules : [60] et [sample;string]. Vous obtiendrez probablement 3 - [60] ["sample;string"]. (HH de plus, qusv permet les chaînes de caractères avec trait d'union :) )
Je sais comment je me débarrasserais de cela en C ou en pluses - allouer d'abord un tableau de pointeurs de chaîne et le remplir en analysant la chaîne. Il n'y a pas de pointeurs dans mcl, je ne comprends pas comment aborder cette tâche. J'espère que Renat pourra clarifier la situation.
"Un tableau de chaînes de fichiers" - qu'entendez-vous par là ? S'il s'agit simplement de créer un tableau qui contiendra toutes les chaînes de caractères, alors, d'après ce que je comprends, la longueur de la chaîne est limitée à un nombre de caractères, non ?
Je veux dire, lire le fichier ligne par ligne et stocker chaque ligne originale du fichier dans un tableau sans l'analyser. Lorsque l'on accède à une chaîne par le format (ligne, colonne), on prend la chaîne ligne, on l'analyse à la volée et on renvoie la valeur de la colonne, en mettant en cache le résultat de l'analyse en même temps.
Voici une autre solution possible. Lorsque vous lisez un fichier, effectuez une analyse syntaxique - enregistrez pour chaque ligne un tableau de deux valeurs entières : l'index du caractère qui commence la valeur de la cellule dans la ligne, et la longueur de cette sous-chaîne.
Par exemple :
строка в файле : 54;345;12;12345
индекс символа : 0 3 7 10
длина подстроки: 2 3 2 5
Il lit les fichiers correctement lorsqu'il n'y a pas de chaînes entre guillemets avec un caractère de délimitation à l'intérieur. Essayez de lire 60 ;""sample;string"" avec ça. Le résultat devrait être 2 cellules : [60] et [sample;string]. Vous obtiendrez probablement 3 - [60] ["sample;string"]. (HH de plus, qusv permet les chaînes de caractères avec trait d'union :) )
Oh, je vois, je ne connaissais pas ces subtilités de la norme CSV. Merci de m'avoir éclairé sur ces particularités !
Je sais comment je m'en débarrasser en C ou en pluses - j'allouerais d'abord un tableau de pointeurs de chaîne et je le remplirais en analysant la chaîne. Il n'y a pas de pointeurs dans mcl, je ne comprends pas comment aborder cette tâche. J'espère que Renat pourra clarifier la situation.
Espérons que Renat pourra nous éclairer.
Je veux dire, lire le fichier ligne par ligne et stocker chaque ligne originale du fichier dans un tableau sans l'analyser. Lors de l'accès à la chaîne par le format (row, column), on prend la chaîne row, on l'analyse à la volée et on renvoie la valeur de column, en mettant en cache le résultat de l'analyse.
Oui, je pense que ce serait optimal dans le temps, même le cache n'est pas vraiment nécessaire, je suppose. Pouvez-vous aider et apporter les modifications appropriées à la classe pour mettre en œuvre cette approche ?
Voici une autre solution possible. Lorsque vous lisez un fichier, effectuez une analyse syntaxique - enregistrez pour chaque ligne un tableau de deux valeurs entières : l'index du caractère qui commence la valeur de la cellule dans la ligne, et la longueur de cette sous-chaîne.
Par exemple :
строка в файле : 54;345;12;12345
индекс символа : 0 3 7 10
длина подстроки: 2 3 2 5
Eh bien oui, c'est à peu près l'approche dont j'ai parlé plus haut aujourd'hui - calculer d'abord ce qui est quoi, puis remplir le tableau. Mais je n'ai aucune idée de la façon de l'implémenter :(
WriteArray / Read sont rapides, taille maximale jusqu'à 300 mb, tout est très rapide, ne consomme pas de RAM
Pourquoi y a-t-il autant de code pour la lecture/écriture, tout est fait en 4 lignes.
WriteArray / Read sont rapides, taille maximale jusqu'à 300 mb, tout est très rapide, ne consomme pas de RAM
Pourquoi y a-t-il autant de code pour la lecture/écriture, tout est fait en 4 lignes.