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
Il y a peut-être une option plus rapide. Mais un pas vers la gauche dans la condition de ce qui doit être compté, et la logique peut devoir changer considérablement. Pas facile, en général.
Ce n'est pas de la mise en cache, c'est de l'indexation. Voici la mise en cache (partie du code) :
Le code a été écrit à la hâte et il y a beaucoup de choses à affiner, étant donné la fréquence des ArrayResize, mais il met exactement à jour le cache, trié par Closed. Si vous souhaitez effectuer une recherche ultérieure, utilisez votre propre index. Mais vous ne devez mettre à jour qu'une petite partie à chaque fois.
Je ne me souviens pas pourquoi"12*3600" est là, je ne pense pas que tous les contrats m'ont été délivrés.
Ce n'est pas une mise en cache, c'est un index.
Veuillez lire attentivement.
Forum sur le trading, les systèmes de trading automatisé et les tests de stratégies de trading
MT5 et la vitesse en action
fxsaber, 2020.08.28 21:10
MQL5 pur est 100x plus lent que la mise en cache partielle (seulement HistorySelectByPosition).
Voici la mise en cache (partie du code) :
Le code a été écrit à la hâte et a quelques choses à améliorer compte tenu des ArrayResize fréquents, mais il met à jour le cache trié par Closed. Si vous souhaitez effectuer une recherche ultérieure, utilisez votre propre index. Mais vous ne devez mettre à jour qu'une petite partie à chaque fois.
Ce n'est qu'un exemple d'une sauvegarde de l'histoire sans les gadgets du monde réel. Même dans MT4Orders, la mise en cache partielle se fait avec une marge de cinq secondes...
Je ne me souviens pas pourquoi"12*3600" est là, je ne pense pas que tous les métiers m'aient été délivrés.
Toujours mettre INT_MAX.
D'un point de vue architectural, la mise en cache complète demande beaucoup de réflexion. Il y a beaucoup de pièges.
Il n'y a vraiment rien de compliqué. Vous pouvez effectuer un échantillonnage en quelques heures, par exemple, pour toutes les commandes qui pourraient apparaître dans l'historique de manière rétroactive (ce qui est très étrange, d'ailleurs).
Ce n'est qu'un exemple de sauvegarde de l'histoire en direct, sans aucun artifice en temps réel. Même dans MT4Orders, la mise en cache partielle se fait avec une marge de cinq secondes...
Toujours mettre INT_MAX.
Je ne comprends pas le but de ce changement. Comme s'il existait un horodatage actuel, je veux me situer par rapport à celui-ci et il est étrange de devoir spécifier un temps qui n'existe pas. Je veux une explication logique.
Mon cache, d'ailleurs, fonctionne sur des comptes réels avec plus de 10 000 transactions.
Et les principaux freins dans le code jusqu'à présent sont les fonctions de réseau.
Dans la dernière version bêta 2588, la fonction HistorySelect est très bien mise en cache et est presque toujours (sauf la première fois) gratuite.
Nous sommes susceptibles d'apporter un certain nombre d'autres améliorations d'ici la sortie de la version.
Comme je l'ai expliqué précédemment, dans MT5, il n'y a pas de coût supplémentaire pour créer automatiquement des instantanés du marché pour chaque EA avant chaque événement, comme cela était fait dans MT4. Cela réduit les délais et permet aux robots de fonctionner plus rapidement. Chaque développeur demande exactement ce dont il a besoin.
Par conséquent, vous devez clairement comprendre que l'approche consistant à "appeler HistorySelect sur l'ensemble de l'historique, puis à effectuer immédiatement une autre sélection de HistorySelectByPosition" tuera les caches de l'historique précédemment créés. C'est un tir dans le pied.
Après la sortie de la version, nous commencerons un travail important pour ajouter de nouvelles fonctions MQL5 plus efficaces et des structures de données natives ouvertes pour les ordres et les transactions, afin de simplifier et d'accélérer l'algotrading.
Dans la dernière version bêta de 2588, la fonction HistorySelect est très bien mise en cache et est presque toujours (sauf la première fois) gratuite.
Résultat.
Sur chaque tique, il y a un problème.
ZY a installé Win10, LatencyMon montre que tout va bien.
Après la sortie de la version, nous commencerons à travailler sur l'ajout de nouvelles fonctions MQL5 plus efficaces et sur l'ouverture des structures de données natives des ordres et des transactions, afin de simplifier et d'accélérer le trading algorithmique.
MqlDeal, MqlOrder et MqlPosition seraient parfaits. Cela pourrait même devenir plus simple.
Pour l'instant, je constate que dans 99% des cas, nous ne devrions utiliser que HistorySelect(0, INT_MAX). Essayez de ne pas utiliser les autres options.
Si j'ai des centaines de milliers de commandes dans mon historique, cela sera-t-il aussi plus rapide que de prendre l'historique de dernière minute ?
Alors dois-je passer par toute cette histoire ? Cela n'a pas de sens.
Si j'ai des centaines de milliers de commandes dans mon historique, est-ce aussi plus rapide que de prendre l'historique de dernière minute ?
Il ne reste que la variante 0-INT_MAX dans les robots de combat. J'ai arrêté de remarquer les décalages.