Erreurs, bugs, questions - page 672
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
Combien de barres y a-t-il dans la fenêtre ?
Le problème est qu'aucune mémoire n'est libérée dans le terminal lorsque le TF est commuté. Lancez le Gestionnaire des tâches, lancez l'indicateur sur le graphique et regardez la mémoire augmenter. Passez ensuite à une autre TF et vous verrez que la mémoire recommence à se développer. Mais logiquement, lorsque vous passez à un autre TF, les données du TF précédent devraient être déchargées de la mémoire. Comme les données de la TF précédente ne sont pas effacées, la mémoire s'agrandit jusqu'à ce qu'elle redémarre et génère une erreur. Si vous retirez votre indicateur du graphique, vous verrez qu'après un certain temps, la mémoire est effacée. Mais il n'est pas effacé lorsque l'indicateur est en marche.
Mon avis : La solution à ce problème est ServiceDec.
Merci, je vais d'abord supprimer l'indicateur avant de changer le TF. En outre, j'ai réduit le nombre maximum de barres dans la fenêtre de 2000000 à 1000000 ; apparemment, MetaDriver veut me le dire.
Jusqu'à présent, cela semble fonctionner.
Merci, je vais supprimer l'indicateur avant de commuter le TF d'abord. En outre, j'ai réduit le nombre maximal de barres dans la fenêtre de 2000000 à 1000000, apparemment MetaDriver veut me le dire.
Jusqu'à présent, cela semble fonctionner.
Pourquoi avez-vous besoin de 100 000 ? 100 000 me suffisent. C'est ce que j'essaie de vous dire.
Il ne limite en aucun cas les essais à une profondeur quelconque.
Il ne limite que (1) l'affichage dans les fenêtres (2) la taille des tampons des indicateurs.
J'ai longtemps et délibérément restreint l'"histoire visible". Résultat : je n'ai aucun problème de mémoire.
Pourquoi avez-vous besoin d'un million ? 100 000 me suffisent, et c'est exactement ce à quoi je faisais allusion.
Il ne limite en aucun cas les essais à une quelconque profondeur.
Il ne limite que (1) l'affichage dans les fenêtres (2) la taille des tampons des indicateurs.
J'ai longtemps et délibérément restreint l'"histoire visible". Le résultat est que je n'ai aucun problème de mémoire.
Oui, merci, je vais utiliser encore plus 108 paires chez InstaForex, pour ne pas avoir de problèmes de mémoire.
C'est un sacré sujet. Aux premiers jours de MT5, je criais que tous les indicateurs devraient avoir un nouveau paramètre standard - le nombre de barres à calculer.
Sinon, nous obtenons le seul limiteur - TERMINAL_MAXBARS. Cela n'est pas acceptable pour les conseillers experts qui analysent de nombreux symboles en temps réel à l'aide d'indicateurs. Dans la plupart des cas (99%), j'ai besoin dans les Expert Advisors d'un nombre strictement spécifié des dernières barres ET TOUTES. Tout le reste est trop pour moi. Bien sûr, pas seulement pour moi...
Il a été ignoré. Par conséquent, j'ai transféré ces calculs dans le code de mon conseiller expert.
Ah oui ! Et l'apparition de nombreux patchs auto-écrits. Certains articles intelligents ont même été écrits et publiés, comme celui qui suit :
Diminuer la consommation de mémoire pour les indicateurs auxiliaires
Mise en œuvre des indicateurs comme classes par les exemples de Zigzag et ATR
...
Si vous séparez les indicateurs réguliers affichés et les indicateurs courts calculés, il sera facile d'obtenir une divergence sur les indicateurs longs cumulés.
Cela conduira également à des béquilles dangereuses de notre côté.
Une bonne solution consiste à définir 100000 barres par graphique ou à passer en x64.
Renat:
Индикаторы на короткой истории нельзя рассчитывать, так как они являются общим разделяющимся между всеми процессами (терминал, окна, эксперты) ресурсом. Причем на индикаторах действуют множество правил обновления, синхронизации и пересчета рыночного окружения.
Если разделить штатные отображаемые индикаторы и короткие расчетные, то легко будет получить расхождение на длинных кумулятивных индикаторах.
Так же это приведет к опасным костылям на нашей стороне.
Хороший способ - устанавливать 100000 баров на чарт или переходить на х64.
En général, rien ne change. Les demandes de possibilité de limiter la taille des tampons d'indicateurs dans MQL5 sont rejetées, et si votre programme commence à consommer une énorme quantité de mémoire en raison des nombreux tampons d'indicateurs utilisés - alors on parle d'"erreur de programmation".
"Dans les Expert Advisors, j'ai le plus souvent (99%) besoin d'un nombre strictement spécifique de dernières barres ET TOUT. Toutes les choses inutiles sont trop pour moi. Pas seulement moi, bien sûr..." (с)
2) Les indicateurs ne peuvent pas être comptés sur un historique court, car ils sont une ressource partagée entre tous les processus (terminal, fenêtres, experts). Et il existe de nombreuses règles de mise à jour, de synchronisation et de recalcul de l'environnement du marché sur les indicateurs.
3. Si vous séparez les indicateurs réguliers affichés des indicateurs courts calculés, il sera facile d'obtenir une divergence sur les indicateurs longs cumulés.
Cela conduira également à des béquilles dangereuses de notre côté.
1. Une bonne solution est de définir 100000 barres par graphique ou de passer en x64.
1. C'est ce que j'ai fait. Pourtant, c'est un compromis inconfortable. Idéalement, si je me détache complètement des problèmes de développement (purement en tant qu'utilisateur), j'aimerais avoir le choix lors du réglage de la durée du calcul. Pour le tableau - toute la longueur (mais pas toujours, il y a de sérieuses et grandes exceptions), pour les experts - exactement la longueur nécessaire. 3.
2. En tant que développeur, je comprends les difficultés et les limites simultanées de cette approche, et pourtant la consommation de mémoire est aussi mon problème, et il s'entête à ne pas vouloir passer au second plan. J'ai une suggestion-solution concrète - considérer la période de calcul (appelons-la ainsi) comme un paramètre égal - pas pire que les autres. Alors deux indicateurs ayant tous des paramètres similaires, mais avec une période de calcul différente, sont simplement deux indicateurs différents. Oui, théoriquement, il y a des cas d'utilisation stupides qui peuvent entraîner des dépenses supplémentaires (si l'utilisateur multiplie les périodes de calcul), mais dans la pratique, c'est peu probable. Si quelqu'un veut aller dans ce sens, il est coupable. Tout comme maintenant TOUS les utilisateurs sont coupables d'avoir "ouvert trop d'indicateurs et n'ont pas pris soin de réduire TERMINAL_MAXBARS".
Je sais que dans le calcul de l'EMA, toutes les barres du début du temps sont utilisées, mais je sais aussi que dans les stochastiques, le RSI et dans un nombre énorme(prédominant) d'autres indicateurs, le calcul est effectué sur une longueur organique . Et cette connaissance me donne la possibilité de choisir la période de calcul (MaxBar), donnez-moi juste le choix.
Autant que c'est maintenant la faute de TOUS les utilisateurs qui "ouvrent trop d'indicateurs et ne prennent pas soin de réduire TERMINAL_MAXBARS".
Oui, surtout dans les conditions de championnat où vous ne pouvez pas du tout influencer la taille de TERMINAL_MAXBARS.
1. Je l'ai fait. Pourtant, c'est un compromis inconfortable. Idéalement, si l'on oublie complètement les problèmes de développement (en tant qu'utilisateur uniquement), j'aimerais avoir le choix de la durée du calcul. Pour le tableau - toute la longueur (mais pas toujours, il y a de sérieuses et grandes exceptions), pour les experts - exactement la longueur nécessaire. 3.
2. En tant que développeur, je comprends les difficultés et les limites simultanées de cette approche, et pourtant la consommation de mémoire est aussi mon problème, et il s'entête à ne pas vouloir passer au second plan. J'ai une suggestion-solution concrète - considérer la période de calcul (appelons-la ainsi) comme un paramètre égal - pas pire que les autres. Alors deux indicateurs ayant tous des paramètres similaires, mais avec une période de calcul différente, sont simplement deux indicateurs différents. Oui, théoriquement, il existe des variantes idiotes qui peuvent entraîner des dépenses supplémentaires (si l'utilisateur multiplie les périodes de calcul), mais dans la pratique c'est peu probable. Si quelqu'un veut dépasser cette bosse - c'est sa propre faute. Tout comme maintenant TOUS les utilisateurs sont coupables d'avoir "ouvert trop d'indicateurs et ne se sont pas souciés de diminuer TERMINAL_MAXBARS".
Je sais que dans le calcul de l'EMA, toutes les barres du début du temps sont utilisées, mais je sais aussi que dans les stochastiques, le RSI et un nombre énorme(prédominant) d'autres indicateurs sont calculés sur une longueur organique . Et cette connaissance me donne la possibilité de choisir la période de calcul (MaxBar), donnez-moi juste le choix.
Le message est clair.
Nous voulons nous-mêmes réduire la consommation de ressources. Peut-être que la solution peut être une fonction IndicatorMaxDepth(uint len) qui n'agira que sur les indicateurs créés dans cet EA.
Mais le problème est que pendant les tests, les tampons des indicateurs en mode accumulation vont croître avec l'historique et il n'y aura pas de sauvegarde. Le découpage de l'historique de l'indicateur en temps réel, tout en maintenant la profondeur spécifiée, est truffé de beaux pépins et fait perdre la tête aux programmeurs, qui comptent/ont l'habitude du synchronisme des barres du graphique et du tampon de l'indicateur.
Une meilleure option est de passer en x64.
Nous allons réviser le cache des indicateurs, qui utilise désormais le principe d'efficacité maximale contre le principe d'économie de mémoire. Nous essaierons de décharger immédiatement les indicateurs qui ont été rejetés, au lieu de les garder en mémoire pendant un certain temps, comme nous le faisons actuellement. Cela permettra d'appeler des centaines d'indicateurs à la suite avec un déchargement direct par IndicatorRelease.
Bien sûr, si quelqu'un veut appeler des centaines d'indicateurs en mode d'analyse du marché sans les décharger, alors il doit passer directement à la version 64 bits + installation de mémoire supplémentaire.
Maintenant, c'est étrange de faire des tests massifs en restant sur x32. Tout ordinateur x64 décent avec 16 Go de mémoire (sans être fanatique des cartes graphiques et des écrans) peut être acheté pour 15 000 roubles.