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
L'impression et l'alerte ne sont pas asynchrones ?
Je voulais rendre ces fonctions asynchrones. J'ai essayé une implémentation via ChartEvent - cela fonctionne. Mais c'est très lent. J'avais déterré ça.
On a renoncé à une fonction aussi coûteuse dans les endroits critiques.
Au sujet d'Alert.
Jusqu'à présent, nous pouvons dire avec certitude qu'Alert n'est pas possible aux endroits critiques. L'asynchronisme est nécessaire.
Reproduit les freins de SymbolInfoTick. Et pas de test de stress. La nécessité pratique vous pousse à l'écrire de cette façon.
Suivez cette instruction pour une relecture rapide.
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading
L'envoi synchrone d'ordres signale une exécution réussie plus rapidement qu'un ping au serveur commercial
fxsaber, 2020.09.30 20:36
Sur une machine rapide, le résultat avec 30 caractères dans Market Watch.
J'espère que je ne suis pas le seul à me reproduire. Bien sûr, le décalage n'est pas aussi important que ce qui a été montré précédemment. Mais il sera possible d'aller au fond des causes beaucoup plus rapidement ici.
ZZY TimeCurrentMsc n'est pas saisi dans MQL5 pour une raison quelconque, malgré des demandes répétées.
On a renoncé à une fonction aussi coûteuse à des endroits critiques.
C'est un inconvénient important. Parce que le modèle d'événement MQL est incomplet - il n'y a pas d'événement zéro, c'est-à-dire l'événement qui est appelé lorsqu'il n'y a pas d'autres événements dans la file d'attente. Elle peut être émulée par un événement personnalisé. Mais compte tenu de cet inconvénient, le modèle événementiel n'a aucun sens pour ceux qui s'intéressent à la vitesse
EventChartCustom est cher.
Qu'en est-il sansChartFirst()?
Et sans ChartFirst() ?
Il est plus coûteux d'envoyer le dossier à quelqu'un d'autre qu'au vôtre.
Il s'agit d'un défaut important. Parce que le modèle d'événement MQL est incomplet - il n'existe pas d'événement nul, c'est-à-dire un événement qui est appelé lorsqu'il n'y a pas d'autres événements dans la file d'attente. Elle peut être émulée par un événement personnalisé. Mais, compte tenu de cet inconvénient, le modèle événementiel n'a aucun sens pour ceux qui s'intéressent à la vitesse.
OnTimer vous permet de passer des appels en arrière-plan avec une fréquence allant jusqu'à 16 ms.
Correct, c'est-à-dire qu'on perd au moins16ms pour rien (on peut revenir au plus tôt).Et nous pourrions n'en perdre aucun s'il y avait un événement nul gratuit ou des événements personnalisés gratuits. Et maintenant le modèle d'événement dans le cas ci-dessous fonctionne de manière limitée :
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.10.06 01:27
Vous êtes complètement à côté de la plaque. Disons que vous devez ouvrir deux positions dans OnTick. Le premier envoi de commande est de quelques millisecondes. Après cela, vous devez faire un cliché. Et ensuite le deuxième OrderSend devrait être appelé.
Seul OnTick peut être exécuté pendant des centaines de millisecondes. Et vous suggérez de prendre un instantané de OnTimer.
Au sujet d'Alert.
Pour l'instant, on peut dire qu'Alert ne peut pas être utilisé dans les endroits critiques. L'asynchronisme est nécessaire.
Alerte avec une empreinte, vous pouvez essayer de la remplacer par une écriture rapide quelque part.
Native sql in memory me vient à l'esprit
Je ne suggérais pas un instantané, je répondais à une question directe sur le minuteur en millisecondes.
J'utilise souvent le fait que le Testeur a exactement une minuterie en millisecondes, et non en secondes. Preuve.
Résultat.
Il y a exactement 29 ms entre l'ouverture et la fermeture de la position.