MT5 et la vitesse en action - page 17
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
Notez que HistorySelect fait un instantané physique de l'historique sélectionné dans le cache local de l'EA, de sorte que vous pouvez les parcourir sans crainte. Sans cela, vous pouvez obtenir des effets très désagréables, car l'historique du compte est mis à jour/synchronisé de manière asynchrone. Sans compter que l'utilisateur lui-même peut modifier manuellement la profondeur de l'historique à partir de l'interface.
D'où ces frais de copie. D'autant plus si vous essayez délibérément de forcer la copie de cet historique dans le cache simultanément à partir de plusieurs threads.
Nous avons déjà beaucoup optimisé les opérations d'échantillonnage et maintenant nous pensons à la mise à jour optimale du cache, alors qu'en réalité 99% des échantillons seront complètement inutiles et seront ignorés à la volée.
En d'autres termes, à moins que vous ne rendiez les limites d'échantillonnage spécifiquement aléatoires, le cache affichera des occurrences proches de 100 %.
La semaine prochaine, il y aura probablement déjà une solution efficace.
Notez que HistorySelect fait un instantané physique de l'historique sélectionné dans le cache local de l'EA, de sorte que vous pouvez les parcourir sans crainte. Sans cela, vous pouvez obtenir des effets très désagréables, car l'historique du compte est mis à jour/synchronisé de manière asynchrone. Sans compter que l'utilisateur peut lui-même modifier manuellement la profondeur de l'historique à partir de l'interface.
Il existe un tableau des commandes et un tableau des transactions. Pourquoi aurions-nous besoin de faire des snaps physiques, alors qu'il suffit de connaître les quatre index au moment de l'appel à HistorySelect ?
C'est pourquoi les frais de copie sont si élevés. Surtout si nous traitons spécifiquement de la copie obligatoire simultanée de cet historique dans le cache à partir de plusieurs threads.
Nous avons déjà beaucoup optimisé les opérations d'échantillonnage et maintenant nous pensons à la mise à jour optimale du cache, alors qu'en réalité 99% des échantillons seront complètement inutiles et seront ignorés à la volée.
En d'autres termes, à moins que vous ne rendiez les limites d'échantillonnage spécifiquement aléatoires, le cache affichera des occurrences proches de 100 %.
La semaine prochaine, il y aura probablement déjà une solution efficace.
HistoryDealSelect et HistoryOrderSelect détruisent désormais les échantillons pertinents. Pourquoi n'y a-t-il pas, comme dans MT4, un accès aux deux tables par les index ? Introduire de nouvelles fonctionnalités.
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading
Bugs, bugs, questions
fxsaber, 2020.08.20 11:28
Nouvelles fonctions internes.Les indices le demandent. Je ne comprends pas pourquoi je devrais connaître le nombre de transactions sur mon compte.
Et ces tableaux peuvent changer à tout moment. Il en va de même pour les enregistrements individuels qui s'y trouvent.
Personne ne peut garantir leur immuabilité en raison des opérations asynchrones, des processus de synchronisation et des modes de profondeur manuels définis par les utilisateurs.
Comme je l'ai écrit plus haut, nous appliquerons des techniques de mise en cache intelligentes, qui réduiront à zéro le coût des fonctions Select. À moins, bien sûr, que vous ne rendiez les limites d'échantillonnage spécifiquement aléatoires. La dernière date peut être modifiée et cela n'invalidera pas le cache si elle est toujours dans le futur/la dernière fois. Les transactions récentes seront ajoutées au cache avec parcimonie.
Dans MT4, cela fonctionne de la même manière, la création du cache est simplement cachée. À chaque OnTick/OnStart de MT4, le terminal crée automatiquement et avec parcimonie un instantané de l'environnement du marché pour chaque EA.
Par conséquent, vous ne pouvez pas évaluer la véritable latence de la préparation des données à partir du code MQL4. Heureusement, dans MT4, les données sont petites et simples.
Dans MT5, nous avons renoncé aux coûts de la création automatique de l'environnement de marché pour réduire les délais et ne pas faire de travail inutile. Au lieu de cela, nous avons donné le contrôle total des coûts aux développeurs de robots qui peuvent demander exactement ce dont ils ont besoin.
Notez que la taille de l'environnement de marché dans MT5 est énorme par rapport à MT4 - il ne peut tout simplement pas être reproduit.
Avec vos tests, vous avez profité d'un de ces échantillons coûteux.
Nous allons y remédier - c'est dans notre intérêt.
Et ces tableaux peuvent changer à tout moment. Il en va de même pour les enregistrements individuels qui s'y trouvent.
Personne ne peut garantir leur immuabilité en raison des opérations asynchrones, des processus de synchronisation et des modes de profondeur manuels définis par les utilisateurs.
Voulez-vous dire qu'avant la dernière transaction, une autre transaction peut apparaître dans l'historique des transactions ? Si un métier a changé, un autre. Mais pour se caler à l'intérieur d'une liste déjà existante - je n'ai pas remarqué cela.
OrderExist et PositionExist sont des fonctions spéciales optimisées qui évitent de parcourir stupidement en boucle tous les ordres ou positions à la recherche d'entrées par symbole, type de transaction et medzhik.
Le résultat est un ensemble de billets.
Les programmes peuvent économiser beaucoup d'argent en utilisant ces fonctions. Surtout lorsqu'on appelle des positions ouvertes et des ordres en masse, de manière constante et répétée dans des boucles de dépassement.
Nous mettrons en œuvre des fonctions plus efficaces pour accéder à des données commerciales massives à l'avenir.
La langue sera également considérablement renforcée et simplifiée grâce à des fonctionnalités plus puissantes.
Voulez-vous dire qu'il peut y avoir une autre transaction dans l'historique des transactions avant la dernière transaction ? Si une affaire a changé, une autre. Mais pour se caler à l'intérieur d'une liste déjà existante - je n'ai pas remarqué cela.
Théoriquement, oui.
N'oubliez pas les processus de synchronisation. Un grand nombre de processus de la plate-forme sont asynchrones.
Par exemple, une intégration de passerelle avec une bourse ou un fournisseur de liquidités peut envoyer des rapports de transaction avec des délais de quelques secondes, voire de quelques minutes. Souvent, l'API ne donne pas du tout accès à l'historique pour la réconciliation, mais fournit des générateurs de rapports lents et non rythmés.
À l'ouverture du marché, ou en raison d'une reconnexion inattendue de la passerelle, les rapports peuvent être retardés. Ils sont répliqués dans l'historique sur le serveur et envoyés immédiatement de manière asynchrone aux terminaux. Grâce au tri par date, ils sont insérés aux bons endroits, et entre-temps vous pouvez ouvrir de nouvelles transactions.
La plupart des API d'intégration sont si illisibles et dysfonctionnelles qu'elles rendent presque impossible la création de passerelles garanties. Bien que certains pensent que c'est le résultat d'un sabotage délibéré de la part de leurs développeurs.
OrderExist et PositionExist sont des fonctions spéciales optimisées qui évitent de parcourir stupidement en boucle tous les ordres ou positions à la recherche d'entrées par symbole, type de transaction et medzhik.
Le résultat est un ensemble de billets.
Les programmes peuvent économiser beaucoup d'argent en utilisant ces fonctions. Surtout lorsqu'on appelle des positions ouvertes et des ordres en masse, de manière constante et répétée dans des boucles de dépassement.
Nous mettrons en œuvre des fonctions plus efficaces pour accéder à des données commerciales massives à l'avenir.
La langue sera également considérablement renforcée et simplifiée grâce à des fonctionnalités plus puissantes.
Renat, une grosse demande pour avoir accès aux cotations en dehors de TERMINAL_MAXBARS lors de l'utilisation des fonctions Copy.... En tout cas, juste le temps d'une minute. Vous pouvez également créer une fonction distincte pour cela.
Mais pour avoir accès à ces données vous devez toujours mettre TERMINAL_MAXBARS à illimité (de plus, cela surcharge le terminal), ce qui est très gênant car vous n'avez pas besoin d'illimité pour tous les symboles.
D'après ce que je comprends, si vous copiez toutes les petites barres de la période MN1, toutes les barres M1 seront toujours téléchargées, mais vous n'y aurez pas accès.
Bien sûr, vous pouvez télécharger tous les ticks, car ils ne sont pas soumis à cette restriction, mais cela prend plus de temps et, malheureusement, les ticks ne coïncident pas toujours avec l'historique complet des minutes.
Renat, une grosse demande pour avoir accès aux cotations en dehors de TERMINAL_MAXBARS lors de l'utilisation des fonctions Copy.... En tout cas, juste le temps d'une minute. Vous pouvez également créer une fonction distincte pour cela.
Mais pour avoir accès à ces données vous devez toujours mettre TERMINAL_MAXBARS à illimité (de plus, cela surcharge le terminal), ce qui est très gênant car vous n'avez pas besoin d'illimité pour tous les symboles.
En effet, d'après ce que je comprends, si vous copiez toutes les petites barres de la période MN1, toutes les barres M1 seront de toute façon téléchargées, mais vous n'y aurez pas accès.
Bien sûr, vous pouvez télécharger tous les ticks car ils ne sont pas soumis à cette restriction, mais cela prend plus de temps et, malheureusement, les ticks ne coïncident pas toujours avec l'historique complet des minutes.
Non, l'historique en dehors de ces limites n'est pas récupéré et vérifié pour la synchronisation. De plus, il n'y a pas d'endroit pour les stocker (nous ne construirons pas de caches invisibles supplémentaires), nous ne monterons pas sur le disque en mode non économique et ne construirons pas de béquilles.
En fait, c'est une mauvaise idée car les développeurs vont immédiatement commencer à écrire des algorithmes absolument inefficaces, conseiller aux traders de "mettre 5000 ou mieux 1000 barres" et nous accuser de lenteur et d'inefficacité.
Nous avons volontairement permis de contrôler la quantité de ressources allouées aux graphiques. Il s'agit de 64 bits et la mémoire est bon marché maintenant - utilisez les paramètres appropriés dans le cadre des règles et de l'architecture.
Nous ne changerons pas ce comportement.
Non, l'historique en dehors de ces limites n'est pas relevé et la synchronisation n'est pas vérifiée. De plus, il n'y a pas d'endroit pour les stocker (nous ne construirons pas de caches invisibles supplémentaires) et nous ne monterons pas sur le disque en mode non économique.
En fait, c'est une idée néfaste, car les développeurs vont immédiatement commencer à écrire des algorithmes absolument inefficaces et conseiller aux traders de "mettre 5000 ou mieux 1000 barres" et nous accuser de lenteur et d'inefficacité.
Nous avons volontairement permis de contrôler la quantité de ressources allouées aux graphiques. Il s'agit de 64 bits et la mémoire est bon marché maintenant - utilisez les paramètres appropriés dans le cadre des règles et de l'architecture.
Nous ne changerons pas ce comportement.
Ok. Je l'ai. Merci. Rayé.
Bien que, bien sûr, j'aimerais débattre de la non-économie. Je devrai laisser illimité et par conséquent tous les ouverts (par exemple j'ai 14 graphiques en ce moment) garderont tout l'historique, bien que je n'ai besoin que de 5000 pour la plupart d'entre eux. Ce qui, au contraire, sera plus anti-économique.
De plus, je n'ai pas besoin que ces données soient stockées. Je m'occupe de l'entreposage. J'ai lancé le chargement de toutes les barres minute, je les ai mises dans un tableau et je n'en ai plus besoin. Tous les caches peuvent être supprimés si leur taille dépasse TERMINAL_MAXBARS. C'est peut-être à cela que sert une fonction séparée qui ne stocke pas les caches.
Bien que, bien sûr, je convienne que des mains coquines peuvent suspendre le système avec de telles charges périodiques.
Vous n'avez que deux états : 5000 et unlim ?
Vous êtes le maître de votre propre bonheur.