![MQL5 - Langage des stratégies de trading intégré au terminal client MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Code de test :
Ce code montre que l'auteur ne comprend pas le problème.
Cet EA obtient le prix Bid du symbole actuel de deux manières. Pour chacun d'entre eux, il additionne le temps d'exécution des cas d'exécution longue. Et montre ensuite la différence entre les deux.
Agents chargés 6/8. J'ai exécuté cet EA sur six graphiques (différents symboles) sur leserveur de démonstrationRannForex. Résultat.
Nous avons une preuve complète que le temps d'exécution total(TimeBid1) de SYMBOL_BID est désastreusement perdant (TimeBid2) pour l'obtention alternative du prix de l'offre.
Cette solution de type béquille pour obtenir les prix actuels bat les performances de la fonction principale de MQL5 elle-même. Êtes-vous d'accord avec cette preuve ?
J'aurais aimé avoir pensé à cette béquille éloquente avant.
ZZZY Pour qu'un EA fonctionne, vous devez autoriser le trading algo. Par conséquent, ne l'exécutez que sur des comptes de démonstration.
Cet EA obtient le prix Bid du symbole actuel de deux manières.
POSITION_PRICE_CURRENT est cassé ?
Alors avec quoi comparons-nous ? Obtenir le dernier prix stocké (quand ?) avec obtenir le dernier prix connu du terminal ?
Bien et environ 6 des 8 cœurs l'ont dit sans détour. Pourquoi de tels tests ?
Ce code montre que l'auteur ne comprend pas le problème.
Votre déclaration prouve que vous ne voulez pas voir l'évidence.
Ce code montre qu'il n'y a pas de "freinage SymbolInfoTick".
Sur du matériel plus ou moins moderne, le temps d'exécution de SymbolInfoTick est inférieur à 1 MICROSeconde.
Ce conseiller expert obtient le prix d'achat du symbole actuel de deux manières. Pour chacun d'entre eux, il additionne le temps d'exécution des cas d'exécution longue. Et puis il montre la différence entre eux.
Agents chargés 6/8. J'ai exécuté cet EA sur six graphiques (différents symboles) sur leserveur de démonstrationRannForex. Résultat.
Nous avons une preuve complète que le temps d'exécution total(TimeBid1) de SYMBOL_BID est désastreusement perdant (TimeBid2) pour l'obtention alternative du prix de l'offre.
Cette solution de type béquille pour obtenir les prix actuels bat les performances de la fonction principale de MQL5 elle-même. Êtes-vous d'accord avec cette preuve ?
J'aurais aimé avoir pensé à cette béquille éloquente avant.
ZZZY Le conseiller expert doit permettre au trading algo de fonctionner. Par conséquent, il peut être utile de l'exécuter uniquement sur des comptes de démonstration.
Non, ce n'est pas une preuve. Un test absolument répugnant qui ne peut être pris au sérieux.
Je ne prendrai même pas la peine d'entrer dans les détails, le fait que vous chronométrez à nouveau un appel unique en utilisant GetMicrosecondCount(), et à nouveau avec "Loaded 6/8 Agents" sur un CPU à 4 noyaux en arrière-plan.
J'ai déjà clairement montré ci-dessus qu'il est possible de trouver des freins imaginaires dans l'exécution de "x++" de cette façon aussi.
Votre affirmation sur les "freins SymbolInfoTick" est élémentairement vérifiée et réfutée par mon code, très simple et évident.
L'implémentation originale de SymbolInfoTick, bien qu'assez rapide, permettait des pics sporadiques de temps d'exécution sur des threads individuels sous une charge de multithreading stressante.
Les dernières versions ne présentent pas non plus cet inconvénient.
C'est tout simplement incroyable que vous continuiez à argumenter avec quelqu'un qui sait exactement de quoi il parle, c'est-à-dire qui voit des implémentations et peut les profiler dans différents modes.
"Discutons du goût des huîtres et des noix de coco avec ceux qui les ont mangées".
POSITION_PRICE_CURRENT est cassé ?
Non. MT4Orders est uniquement utilisé pour placer une position.
Alors avec quoi comparons-nous ? Obtention du dernier prix enregistré (quand ?) vs. obtention du dernier prix connu du terminal ?
Nous comparons la durée de l'obtention des prix par Market Watch et la position. Les prix coïncident bien sûr.
Et environ 6 des 8 cœurs ont dit directement. Pourquoi de tels tests ?
Seulement pour que même un aveugle voit qu'il y a un problème. C'est un non-sens, lorsque le prix d'achat ne ralentit pas via la position et que le SymbolInfoTick est horriblement lent.
Je pense que ce mur de MQ ne peut être brisé sans le soutien des utilisateurs du forum. Le code est court, les professionnels devraient pouvoir l'appréhender rapidement. Il n'y a aucun défaut. Il est clairement démontré que les prix à travers les positions sont obtenus beaucoup plus rapidement qu'à partir de Market Watch. Comment les MQ ne voient pas l'évidence - je ne comprends pas.
Votre déclaration prouve que vous ne voulez pas voir l'évidence.
Ce code montre qu'il n'y a pas de "freinage SymbolInfoTick".
Sur du matériel plus ou moins moderne, le temps d'exécution de SymbolInfoTick ne dépasse pas 1 microseconde.
Non, ce n'est pas une preuve. Un test absolument désordonné qui ne peut être pris au sérieux.
Je ne prendrai même pas la peine d'entrer dans les détails, le fait que vous mesuriez une fois de plus le temps d'un seul appel par GetMicrosecondCount(), et une fois de plus sur fond de "Loaded 6/8 Agents" sur un CPU à 4 cœurs est suffisant.
J'ai déjà clairement montré ci-dessus qu'il est possible de trouver des freins imaginaires dans l'exécution de "x++" de cette façon aussi.
Votre affirmation sur les "freins SymbolInfoTick" est élémentairement vérifiée et réfutée par mon code, très simple et évident.
L'implémentation originale de SymbolInfoTick, bien qu'assez rapide, permettait des pics sporadiques de temps d'exécution sur des threads individuels sous une charge de multithreading stressante.
Dans les dernières versions, il n'a pas non plus cet inconvénient.
C'est tout simplement incroyable que vous continuiez à argumenter avec quelqu'un qui sait exactement de quoi il parle, c'est-à-dire qui voit des implémentations et peut les profiler dans différents modes.
"Discutons du goût des huîtres et des noix de coco avec ceux qui les ont mangées".
Vous n'avez pas regardé le code. Je ne crois pas à l'incompétence.
C'est une condition où l'exécution ne compte que si elle a duré plus de 100µs. Si vous pensez que c'est une petite valeur, faites-en un ordre de grandeur plus long. L'effet est le même.
Les deux fonctions comparées sont dans des conditions absolument égales. L'un freine à la fin, l'autre non. Regardez de plus près ce que le code mesure.
Pour le moment, le remplacement de SymbolInfoTick dans les EA de combat par la béquille suggérée supprime presque tous les décalages associés à l'obtention des prix actuels. C'est délirant, mais malheureusement c'est le cas.
HI Notez le while dans OnTick. C'est délibérément fait pour attraper les tics qui sont arrivés après que OnTick ait été accepté. Le code n'a pas été écrit à l'improviste. Il ne s'agit pas d'un for-cycle totalement artificiel mesurant la température moyenne d'un hôpital dans des conditions idéales.
Je pense que ce mur de QM ne passera pas sans le soutien des membres du forum. Le code est court, les pros devraient pouvoir le comprendre rapidement. Il n'y a aucun défaut. Il est clairement démontré que les prix à travers les positions sont obtenus beaucoup plus rapidement qu'à partir de Market Watch. Comment MQ ne peut pas voir l'évidence - je ne comprends pas.
Il n'y a pas d'erreurs dans le code, donc SymbolInfoTick est plus lent que d'obtenir le prix d'une position ouverte.
Joli coup pour obtenir le prix à partir de la position, je n'aurais pas deviné ou réalisé qu'il pouvait y avoir une telle différence.Seulement pour que même un aveugle voit qu'il y a un problème. Eh bien, c'est un non-sens lorsque le prix de l'offre à travers la position n'est pas lent, mais que SymbolInfoTick est terriblement lent.
Essayez de tester SymbolInfoTick lorsqu'il n'y a qu'un seul symbole dans l'aperçu du marché et lorsqu'il y a des dizaines de symboles, mais demandez un seul symbole - comme dans votre exemple
il est très probable que le serveur ait compressé le trafic et que SymbolInfoTick ait ce décalage intermittent lors de la décompression des données.
c'est-à-dire que lorsqu'il y a beaucoup de personnages, il y aura des creux encore plus fréquents ou plus profonds dans le temps de test.
donc si cela s'avère être vrai, alors refaire toute l'architecture.... plaisir discutable
essayez de tester SymbolInfoTick quand il y a un symbole dans la vue d'ensemble du marché et quand il y a des dizaines de symboles, mais demandez un seul outil - comme dans votre exemple
il y a une forte probabilité que le serveur envoie du trafic compressé et que SymbolInfoTick connaisse ce ralentissement intermittent lors de la décompression des données.
c'est-à-dire que lorsqu'il y a beaucoup de symboles, les creux dans le temps de test seront encore plus fréquents ou plus profonds.
Cette hypothèse fait référence au cas où les prix dans le Market Watch sont en retard sur les prix du tumblr (et vice versa). Mais jusqu'à présent, nous ne parlons que du freinage du SymbolInfoTick lui-même à l'intérieur du Terminal, sans toucher à la question de la pertinence du prix.
Les deux fonctions comparées sont exactement dans les mêmes conditions.
Au moins GetBid est appelé après SymbolInfoDouble. Si nous les intervertissons, le résultat sera-t-il le même ?
Quelque chose me dit quePOSITION_PRICE_CURRENT prend le prix stocké, et non le prix frais.
Mais encore une fois, je ne vois pas l'intérêt de faire des tests sur un CPU chargé à 80%. Nous testons les performances du processeur et l'allocation des ressources par le windup, pas les fonctionnalités dont nous avons besoin.
Au moins GetBid est appelé après SymbolInfoDouble. Si vous l'échangez, le résultat sera-t-il le même ?
Je l'ai expérimenté avant de le publier. Non, cela n'affecte pas le résultat.
Quelque chose me dit quePOSITION_PRICE_CURRENT prend le prix stocké, et non le prix frais.
C'est là le problème, les programmes MQL ont besoin du dernier prix qui est arrivé sur le terminal, pas d'autre chose. Lorsqu'un tick entre dans le Terminal, il met automatiquement à jour tous les tableaux de positions/ordres.
Bien et encore, je ne vois pas l'intérêt de tester sur un CPU chargé à 80%. Nous testons les performances de l'unité centrale et l'allocation des ressources à la chaîne, et non les fonctionnalités dont nous avons besoin.
La principale condition est que l'environnement soit identique pour les deux fonctions. La charge du processeur est le facteur le plus frappant pour la visibilité des écarts.
Vingt EAs en parallèle peuvent parfois faire un appel SymbolInfoTick en même temps, il y a alors une salve de millisecondes de charge et de décalages. J'ai seulement suggéré de le faire explicitement pour que le problème soit immédiatement perceptible.
Là encore, les conditions d'essai sont identiques pour les deux fonctions. Fait.
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie
MT5 et la vitesse en action
fxsaber, 2020.10.26 17:53
Pour l'instant, le remplacement de SymbolInfoTick dans les EA de combat par la béquille suggérée supprime presque tous les freins associés à l'obtention des prix actuels. C'est délirant, mais malheureusement c'est le cas.