Théorie de l'accélération de l'EA lors de l'utilisation d'un indicateur personnalisé (fonction - iCustom) - page 5
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
Pouvez-vous décrire la tâche. Que doit faire le script avec toutes les barres ? Je pense que vous essayez de résoudre le problème de front. Il est difficile de donner des conseils sans voir le problème à résoudre.
J'ai le script, voici les TdRhttps://www.mql5.com/p/21/234411 , mais il y a des difficultés de fonctionnement dues au manque de mémoire..... ou plutôt il s'épuise après une courte exécution du script.
La page est interdite. Que vous ayez un script, c'est bien, mais cela ne résout pas le problème. Que fait le script ?
Renat répond qu'il n'y a qu'un seul moyen - transférer une partie du calcul d'un indicateur dans un script.
Je comprends, mais cela rend le travail plus compliqué et augmente considérablement mes coûts. Cela rend l'outil (le script) peu polyvalent.
Vous pouvez également faire preuve de masochisme et décomposer la gamme de paramètres calculés en sous-gammes. Et exécuter le script en changeant les paramètres dans chaque sous-gamme. Cela prend du temps, je sais, mais que pouvons-nous faire ?
Maintenant, je pense que la solution pourrait être d'automatiser le processus d'ouverture d'un graphique par le script, de calculer quelques indicateurs sur celui-ci, de fermer le graphique par le script et d'en ouvrir un nouveau - cela permettra de vider la mémoire ?
La deuxième option est de passer à 5. C'est-à-dire que nous devrions rechercher les paramètres optimaux sur le 5ème indicateur et ensuite substituer les paramètres optimaux dans le 4ème indicateur. Dans le 5, il est possible de gérer le chargement et le déchargement des indicateurs. Mais les opérations de chargement/déchargement sont très gourmandes en ressources.
Je pense qu'il est préférable d'avoir des opérations coûteuses que de ne pas en avoir, et je comprends que plus de mémoire peut être utilisée en 5, mais j'ai besoin d'indicateurs qui ont été écrits pour 4, parce que je trade sur 4...
Mes calculs sont basés sur le premier et je ne sais pas comment convertir l'indicateur en 5, mais il est possible de rendre les indicateurs compatibles entre eux, du moins après la compilation ...
La commande pour ajouter un indicateur au graphique n'a pas été trouvée. En supprimant le tableau, vous libérez bien sûr de la mémoire. Mais lorsque vous fermez le graphique, tous les indicateurs du graphique sont fermés.
Il existe une commande pour ouvrir de nouveaux graphiques, mais il n'y a pas de commande pour attacher l'indicateur au graphique nouvellement ouvert. C'est pourquoi l'automatisation réelle ne fonctionnera pas non plus dans ce cas.
L'appel d'un indicateur via iCustom() n'ajoute pas un graphique au graphique.
Si vous ne mettez pas le graphique sur le graphique, alors quel graphique allez-vous supprimer pour libérer de la mémoire ?
Ne perdez pas votre temps, faites confiance à Renate.
Je me trompe peut-être. Revoyons tout ça :
1. Il y a un script qui appelle la fonction de l'indicateur iCustom et sauvegarde les tampons du graphique en mémoire.
2. L'appel à la fonction iCustom est multiple - en conséquence, la RAM est remplie et l'indicateur renvoie des zéros.
Le terminal doit pouvoir fonctionner avec de la mémoire, non ? Pour vider le cache, si je comprends bien, c'est possible si les données ne sont pas nécessaires, et elles ne sont pas nécessaires si le graphique avec les données est supprimé.
4. Supprimez le graphique et libérez de la RAM pour les autres calculs du point 1.
Où ai-je tort ?
P.S. D'après ce que je comprends, les données sont toutes liées au graphique sur lequel le calcul est effectué - peu importe les guillemets utilisés pour cela.
Je me trompe peut-être. Revoyons tout ça :
1. Il existe un script qui appelle la fonction de l'indicateur iCustom et stocke les tampons graphiques en mémoire.
2. La fonction iCustom est appelée plusieurs fois - en conséquence, la RAM est remplie et l'indicateur renvoie des zéros.
Le terminal doit pouvoir fonctionner avec de la mémoire, non ? Pour vider le cache, comme je le comprends, c'est possible si les données ne sont pas nécessaires, et elles ne sont pas nécessaires si le graphique avec les données est supprimé.
4. Supprimez le graphique et libérez de la RAM pour les autres calculs du point 1.
Où ai-je tort ?
P.S. D'après ce que je comprends, les données sont liées au graphique sur lequel le calcul est effectué - les guillemets utilisés à cet effet n'ont aucune importance.
Au point 3.
Le terminal conserve le cache des séries temporelles et des indicateurs construits sur celles-ci pendant un certain temps après la fermeture, afin de ne pas tout recalculer d'un coup au prochain appel.
Au point 3.
Le terminal conserve le cache des séries temporelles et des indicateurs basés sur celles-ci pendant un certain temps après la fermeture, afin de ne pas tout recalculer d'un coup lorsque vous y accédez à nouveau.
Mais qu'est-ce qu'un "certain" temps ? Peut-être existe-t-il d'autres critères/méthodes pour libérer les ressources (retirer le cache de la mémoire) ?
Non, Renat a déjà répondu.
Dans MT5, le cache est vidé si le conseiller expert qui utilise des indicateurs comme ressources est déchargé. Par exemple, vous pouvez charger un graphique avec un conseiller expert, en lire une partie, et fermer le graphique. Mais ce n'est toujours pas très rapide.
Je ne sais pas dans MT4.
Non, Renat a déjà répondu.
Dans MT5, le cache est vidé si le conseiller expert qui utilise des indicateurs comme ressources est déchargé. Par exemple, vous pouvez charger un graphique avec un conseiller expert, en lire une partie, et fermer le graphique. Mais ce n'est toujours pas très rapide.
Je n'en sais rien dans MT4.
La mémoire est libérée après l'opération du script. Donc, la mémoire pour le calcul des données obtenues de l'indicateur est libérée, mais cela ne concerne pas les tampons du graphique, n'est-ce pas ?
Et si nous traduisons les données non pas par le tampon graphique, mais autrement - par des variables globales, par exemple (je ne sais pas si un tampon peut être créé à cet endroit), alors l'effet du manque de mémoire peut être surmonté ?
1. ouvrez le tableau et le "gestionnaire des tâches" - mémoire utilisée 215692 kb
2. J'applique l'indicateur - mémoire occupée 219612 kb (augmentation 3920 kb)
3. Suppression de l'indicateur - mémoire utilisée 217984 kb (libérée 1628 kb)
Et les 2292kb restants de mémoire non libérée, si je comprends bien, sont allés dans le cache ?
Le tampon ne prend-il pas trop de données - historique de février 2013 sur le Sentry.