MT5 et la vitesse en action - page 63
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
Chers développeurs, pourriez-vous me dire comment est calculé MQL_MEMORY_USED ?
J'ai fait un calcul de la mémoire qu'occupent toutes les variables EA.
Il est inférieur à 10%. Si je comprends bien, MQL_MEMORY_USED inclut le cache de l'historique et le cache des CopyTicks. Mais c'est toujours beaucoup moins.
Dans le même temps, le conseiller expert parallèle consomme plusieurs fois moins. Mais le principe est le même.
En général, qu'est-ce qui est inclus dans cette valeur ?
J'ai enregistré un modèle avec Expert Advisor et je l'ai appliqué au même graphique en provoquant un rechargement. Je l'ai vu comme ça.
L'utilisation de la mémoire a changé de près d'un ordre de grandeur. Jusqu'à présent, il est difficile d'expliquer ce que cela signifie.
De nombreux programmes ont un effet cumulatif sur l'utilisation de la mémoire. C'est un péché des navigateurs et parfois même de Word. Le terminal peut également s'en rendre coupable. De plus, tous les journaux sont écrits par défaut et il est facile de passer une semaine si vous avez trop d'actions dans un giga. C'est un mal qu'il faut gérer. Mais il n'est pas clair comment.
Peut-être savez-vous comment sélectionner par programme un instrument financier et ne pas rester bloqué pendant des heures ?
Par le biais d'un indicateur
Forum sur le trading, les systèmes de trading automatisé et les tests de stratégies de trading
MT5 et la vitesse en action
Renat Fatkhullin, 2020.10.14 04:15
Pour le tic-tac de masse, mettez plus de mémoire.
4gb (prix 20€) n'est pas bon en 2020 quand il s'agit d'analyse et de recherche.
Pour les produits du marché, cette approche n'est bonne nulle part. Nous devons contourner la rétention de 10 secondes de données inutiles grâce à une telle béquille.
La création d'un produit de marché trivial sous la forme d'un Market Screener n'est en fait pas une tâche réalisable pour MT5 en raison de la consommation excessive de mémoire.
La création d'un produit de marché trivial sous la forme d'un Market Screener n'est en fait pas une tâche réalisable pour le MT5 en raison de la consommation excessive de mémoire.
Le terminal consomme beaucoup de mémoire après le lancement.
Après l'exécution du screener il a commencé à manger 2 gigs (TERMINAL_MEMORY_USED et n'a pas diminué avec le temps). Ceci avec un seul graphique ouvert pour 5000 barres M1.
Je n'ai pas enregistré de capture d'écran. Mais j'ai décidé de donner un exemple, qui montre que le terminal de consommation de mémoire n'est pas en soi, où c'est juste stupide.
Le script fait simplement des copies des symboles originaux du Market Watch. J'étais censé ajouter tous les symboles sur MQ-Demo et exécuter ce script une première fois à froid, puis une seconde fois à chaud.
Et après l'exécution à chaud (lorsque les tics sont déjà sur le SSD sous la forme de fichiers tkc), j'observerai un énorme épuisement de la mémoire là où il n'est pas nécessaire dans une mise en œuvre correcte.
Cependant, en exécutant le script, j'ai constaté qu'il se bloque sur MQ-Demo. Il ne peut être déchargé que par une terminaison anormale, après quoi le terminal ne libère pas plus de 1 Go de mémoire.
Il est facile de comparer cette capture d'écran avec celle du début.
Désolé, je ne sais pas si c'est un bug ou une fonctionnalité. Je n'ai pas trouvé de réponse par moi-même. Mais la question est liée aux performances et je suppose qu'il est préférable de la poser ici.
Si nous ajoutons, par exemple, 22 tampons de type DRAW_SECTION à un indicateur vide, alors au démarrage d'un tel indicateur pour un graphique contenant 1000000 barres ou plus, le terminal accuse un retard significatif (il provoque une charge CPU importante) et consomme des quantités importantes de mémoire, même si l'indicateur ne calcule rien.
Mon intérêt a été éveillé par le fait que si vous utilisez des tampons avec d'autres types, tout fonctionne sans problème et un tel ralentissement n'est pas observé.
Par exemple, j'ai exécuté le code suivant sur un seul graphique avec 1000000 barres et il a consommé environ 500 MBytes et traîne, surtout le graphique lui-même.
Mais si je change le type de tampon pour, disons, DRAW_LINE, la charge sur le processeur est réduite de façon spectaculaire, les décalages ne sont pas observés, et la mémoire consomme 5 fois moins (environ 100 MBytes consommés).
Des tests similaires ont été effectués sur différentes builds, jusqu'aux builds 2019 et la situation est la même.
Un citoyen a sorti de son pantalon largeun double d'une précieuse charge de code MQL, qui montrait que, dans les mêmes conditions, la béquille fonctionnait plus vite que la fonction régulière.
Un test très simple :
20 Expert Advisors sur EURUSD, c'est-à-dire tous les processus OnTick simultanément. La construction du terminal est de 2664. Le test est exécuté sans optimisation, compilation et autres charges supplémentaires à 100 % du processeur - vous n'allez pas exécuter une véritable transaction "hft" sur ce fond, n'est-ce pas ?
Journal d'essai typique :
Un test très simple :
20 EAs sur EURUSD, c'est-à-dire tous les processus OnTick en même temps. Terminal build 2664. Le test est exécuté sans optimisation, compilation et autre charge de travail supplémentaire sur un CPU à 100% - vous n'allez pas exécuter un véritable trading "hft" sur ce fond, n'est-ce pas ?
Journal d'essai typique :
Vous créez des conditions de serre en effectuant 100 000 itérations pendant 1,5 seconde sur le même tick. D'autre part, j'ai volontairement attendu des ticks qui ne généraient pas de OnTick.
En examinant mes journaux de transactions, je remarque que l'exécution de SymbolInfoTick se fait en quelques millisecondes. Et je sais à 100% que le processeur était en veille à ce moment-là.
C'est très simple. Il y a conditionnellement 1 million de tiques par jour. Même un ralentissement de 0,01% des ticks représente 100 ticks par jour avec des décalages. Vous direz que c'est absurde. Je dirai que c'est mauvais. Si je rencontre un retard lorsque je dois passer une commande, c'est une perte monétaire potentielle.
Très reconnaissant que cette branche ne passe pas inaperçue, et sur cette fonctionnalité en particulier, beaucoup de travail a été fait pour accélérer les choses. Cependant, j'ai été un peu surpris de constater que l'horrible béquille pouvait surpasser la fonction régulière dans certaines situations. Et peut-être qu'en faisant le tri et en éliminant ce décalage, les 100 décalages potentiels par jour se transformeraient en 10.
Je dis que c'est bien mieux qu'au début du fil. Mais le fait est qu'il y a des moments où ce n'est pas bon. Et je vois que tu ne veux pas y réfléchir. Je respecte votre choix.
Nous avons cité plus haut l'option de l'instantané pour obtenir les prix actuels. Cela me conviendrait parfaitement s'il n'y avait pas de décalage de quelques millisecondes sur la machine à processeur inactif.
Je m'inquiète également non seulement de la vitesse de SymbolInfoTick, mais aussi de la pertinence des prix qu'il renvoie. Je vois que vous ne soulevez pas cette question. Apparemment, vous avez décidé de le regarder plus tard.
Vous créez des conditions de serre en effectuant 100 000 itérations en 1,5 seconde sur le même tick. D'un autre côté, j'ai spécifiquement attendu les ticks qui ne génèrent pas de OnTick.
En examinant mes journaux de transactions, je remarque que SymbolInfoTick fonctionne pendant quelques millisecondes. Je sais à 100% que le processeur était complètement inactif à ce moment-là.C'est très simple. En une journée, il y a conditionnellement 1 million de tiques. Même un décalage de 0,01 % représente 100 ticks par jour avec des décalages. Vous direz que c'est absurde. Je dirai que c'est mauvais. Si je rencontre un retard lorsque je dois passer une commande, c'est une perte monétaire potentielle.
Très reconnaissant que cette branche ne passe pas inaperçue, et sur cette fonctionnalité en particulier, beaucoup de travail a été fait pour accélérer les choses. Cependant, j'ai été un peu surpris de constater que l'horrible béquille pouvait surpasser la fonction régulière dans certaines situations. Et peut-être qu'en faisant le tri et en éliminant ce décalage, les 100 décalages potentiels par jour se transformeraient en 10.
Je dis que c'est bien mieux qu'au début du fil. Mais le fait est qu'il y a des moments où ce n'est pas bon. Et je vois que tu ne veux pas y réfléchir. Je respecte votre choix.
Nous avons cité plus haut l'option de l'instantané pour obtenir les prix actuels. Cela me conviendrait parfaitement s'il n'y avait pas de décalage de quelques millisecondes sur la machine à processeur inactif.
Je m'inquiète également non seulement de la vitesse de SymbolInfoTick, mais aussi de la pertinence des prix qu'il renvoie. Je vois que vous ne soulevez pas cette question. Apparemment, vous avez décidé de le regarder plus tard.
Ce ne sont pas du tout des conditions chaudes. Une boucle pour 100000 demandes de prix sans Sleep() et autres et dans 20 threads simultanément est un test de stress évident. Rien de tout cela ne devrait être proche en conditions réelles.
Si vous pensez qu'il n'y a pas d'autres tics à venir dans 1,5 seconde - ok, faites 10 millions de requêtes, cela ne changera rien, votre "béquille" fonctionne moins bien :Cette affirmation est fausse à 100% :
Tout comme votre précédente déclaration :
L'accès aux prix via SymbolInfoTick est maintenant très rapide et complètement découplé du traitement des flux de tick. Vous travaillez avec un cache prix prêt à l'emploi, qui est mis à jour très parcimonieusement et rapidement.
Tous les "ralentissements du taux de tic-tac de 0,01 %" ne se manifestent que dans des conditions de test de stress, et c'est un excellent résultat. Dans des conditions normales, l'accès est garanti très rapide.
Si vous admettez que "beaucoup de travail a été fait pour accélérer" SymbolInfoTick, alors vous devriez me croire que la "béquille" consistant à obtenir les prix via PositionSelectByTicket ne peut pas être une meilleure solution.
Pour une raison simple : l'implémentation de PositionSelectByTicket est complètement identique à l'implémentation "lente" originale de SymbolInfoTick.
Comme je l'ai écrit plus haut, cette implémentation n'est pas lente au sens littéral du terme, mais sous une forte charge CPU, elle a une probabilité plus élevée d'apparition d'aberrations d'exécution (ce qui est clairement visible dans mon dernier test).
Les délais dépendent fortement du planificateur de tâches du système fonctionnant sous charge, c'est-à-dire qu'il peut y avoir des différences d'un système d'exploitation à l'autre et même d'une version à l'autre.
Et plus la charge est lourde, plus vous testez les performances du planificateur de tâches, et non du terminal.
C'est la fin du sujet sur la performance de SymbolInfoTick.
Si vos experts créent une charge du niveau des tests de stress synthétiques, il existe une solution : "le fer doit correspondre aux tâches".
J'ai une question sur la pertinence des ticks donnés par SymbolInfoTick.
Situation :
1. Nous faisons TimeCurretn() ; nous obtenons le temps 18:00:00
2. Effectuer SymbolInfoTick sur un symbole invalide. Nous obtenons un tic-tac avec l'heure 17:58:00.
3. Sommeil(1)
4. Ajoute un SymbolInfoTick pour le symbole non gauche. Nous obtenons un tick avec l'heure 17:59:00.
C'est-à-dire que dans le quatrième élément, nous avons un nouveau tick, qui est différent d'une minute de TimeCurretn().
Voyez-vous un problème dans cette situation ?
Comment se retrouver moins souvent dans cette situation ?
J'ai une question sur la pertinence des ticks donnés par SymbolInfoTick.
Situation :
1. Nous faisons TimeCurretn() ; nous obtenons le temps 18:00:00
2. Effectue SymbolInfoTick sur un symbole non étiqueté. Nous obtenons un tic-tac avec l'heure 17:58:00.
3. Sommeil(1)
4. Ajoute un SymbolInfoTick pour le symbole non gauche. Nous obtenons un tick avec l'heure 17:59:00.
C'est-à-dire que dans le quatrième élément, nous avons un nouveau tick, qui est différent d'une minute de TimeCurretn().
Voyez-vous un problème dans cette situation ?
Comment se retrouver moins souvent dans cette situation ?
SymbolInfoTick envoie les données reçues du serveur du courtier. Ce que le serveur a envoyé est ce que vous recevez.
Si vous avez des questions sur le flux de tic-tac diffusé par votre courtier, vous devez contacter votre courtier.