Erreurs, bugs, questions - page 2776

 
Nikolai Semko:

Mais pourquoi alors les fonctions ChartGetInteger, ChartGetDouble, ChartGetString se comportent-elles de manière asynchrone en termes de vitesse d'exécution, alors qu'elles sont synchrones ?

Vous avez une mauvaise compréhension des termes "asynchrone" et "synchrone".
Lorsqu'on dit qu'une fonction est asynchrone, cela signifie qu'elle sera exécutée non pas dans le fil d'exécution actuel mais dans un autre fil - un fil parallèle.

La fonction est asynchrone - cela signifie que la fonction n'attend pas l'exécution de la commande mise en file d'attente avec succès dans le tableau spécifié mais retourne immédiatement le contrôle.
La propriété ne sera modifiée qu'après le traitement de la commande dans la file d'attente des cartes.
LafonctionChartRedrawdoit être appelée pour exécuter immédiatement les commandes de la file d'attente des graphiques.

L'appel de la fonction asynchrone ChartSetInteger à partir du thread principal est rapide car l'exécution réelle a lieu dans un autre thread.


D'autre part, l'appel de la fonction synchrone ChartGetInteger nécessitera la synchronisation des threads, ce qui peut prendre du temps supplémentaire.
Le retard est particulièrement sensible lorsque le thread parallèle met constamment à jour les données de la structure graphique (par exemple, lorsque l'utilisateur déplace la fenêtre du graphique ou fait défiler l'historique).
Le plus souvent, pour des raisons de simplicité et de fiabilité, un seul objet de synchronisation est utilisé pour sa structure de données graphique.
Vous pouvez essayer d'améliorer la vitesse d'exécution en utilisant la "segmentation des données", mais d'un autre côté, vous pouvez maintenant vous heurter à des blocages, à des données insuffisamment mises à jour ou à des ralentissements à d'autres endroits plus critiques.
En général, il est préférable de ne pas toucher à quelque chose qui fonctionne déjà bien.

 
Sergey Dzyublik :

Vous avez une mauvaise compréhension des termes asynchrone et synchrone.
Lorsqu'on dit qu'une fonction est asynchrone, cela signifie qu'elle sera exécutée non pas dans le fil d'exécution actuel, mais dans un autre fil.

L'appel d'une fonction asynchrone comme ChartSetInteger à partir du thread principal est rapide car l'exécution réelle se produit dans un thread différent.


En revanche, l'appel d'une fonction synchrone ChartGetInteger nécessitera la synchronisation des threads, ce qui peut prendre du temps supplémentaire.
Le retard est particulièrement sensible lorsque le thread parallèle met constamment à jour les données de la structure graphique (par exemple, lorsque l'utilisateur déplace la fenêtre du graphique ou fait défiler l'historique).
Le plus souvent, pour des raisons de simplicité et de fiabilité, un seul objet de synchronisation est utilisé pour sa structure de données graphique.
Vous pouvez essayer d'améliorer la vitesse d'exécution en utilisant la "segmentation des données", mais d'un autre côté, vous pouvez maintenant vous heurter à des blocages, à des données insuffisamment mises à jour ou à des ralentissements à d'autres endroits plus critiques.
Dans l'ensemble, il est préférable de ne pas toucher à quelque chose qui fonctionne déjà de manière stable.

Vous avez raison, mais il semble y avoir des goulots d'étranglement. Le marché est maintenant fermé, j'ai exécuté le code ci-dessous sur 1 graphique, rien d'autre ne fonctionne. Il est exécuté sur un VPS avec seulement MT5 en cours d'exécution et je n'ai pas interagi avec le graphique / MT5 avec autre chose qu'une capture d'écran. Temps en µs, 127 µs en moyenne, mais le pic est de 43,995 µs.


Dossiers :
342152.mq5  5 kb
 

Messieurs les développeurs !

Veuillez me corriger si j'ai écrit dans le mauvais fil. Il y a des suggestions pour faciliter l'utilisation et le débogage, qui seront utiles pour beaucoup, et qui sont importantes pour moi.


1. Augmentez la longueur de la ligne OBJPROP_TOOLTIP pour les objets (2 fois suffisent). Pour les stratégies comportant beaucoup de graphiques, la longueur actuelle est très courte. Pour le débogage, vous devez consacrer du temps à chaque fois pour faire entrer toutes les données nécessaires. Vous devez ensuite modifier et/ou ajouter régulièrement des réductions pour les consommateurs.


2. Augmentez la longueur des commentaires aux noms des paramètres d'entrée (2 fois est suffisant). Les commentaires sur les paramètres d'entrée sont nécessaires pour le consommateur. Et s'il y a un grand nombre, il est également pratique de faire une numérotation supplémentaire. Pour l'optimisation, il est important de connaître le nom de la variable. Par conséquent, il n'est souvent pas possible de tout faire rentrer dans la longueur actuelle. Exemple :


3. Diversifier la sélection des colonnes dans le tableau des résultats d'optimisation - jusqu'à et y compris l'affichage de toutes les colonnes deENUM_STATISTICS et laisser l'utilisateur choisir ce dont il a besoin. C'est untrès mauvais choix pour l'analyse. Le drawdown en % est inutile lors de l'optimisation avec un volume fixe. Il n'y a pas de possibilité de choisir le tirage maximal en termes de devise et de dépôt. Parfois, il existe un fort biais entre les positions d'achat et de vente lors de l'optimisation, mais vous ne pouvez le découvrir qu'après avoir effectué un seul test. Nous devons souvent saisir les paramètres manquants dans le champ de résultat(STAT_CUSTOM_ONTESTER). Mais nous voulons y afficher des critères de résultat supplémentaires, et il est possible de n'en afficher qu'un seul, ce dont nous pourrions encore nous accommoder, si nous avions fait varier le nombre de colonnes de critères standard deENUM_STATISTICS. En somme, je dois consacrer beaucoup de temps supplémentaire à la sur-optimisation et à l'analyse.

Merci !

 
Alain Verleyen:

Vous avez raison, mais il semble y avoir des goulots d'étranglement. Le marché est maintenant fermé, j'ai exécuté le code ci-dessous sur 1 graphique, rien d'autre ne fonctionne. Il est exécuté sur un VPS avec seulement MT5 en cours d'exécution, et je n'ai pas interagi avec le graphique / MT5 avec autre chose qu'une capture d'écran. Le timing est en µs, 127 µs en moyenne, mais le pic est de 43,995 µs.

Je suppose que le pic correspond au rendu du commentaire du graphique, sinon, lorsque la file d'attente des graphiques est vide, l'appel de la fonction ChartGetXXX (notez l'appel avec synchronisation) prend 0,13 milliseconde.

 
Sergey Dzyublik:

Vous avez une mauvaise compréhension des termes asynchrone et synchrone.
Lorsqu'on dit qu'une fonction est asynchrone, cela signifie qu'elle sera exécutée non pas dans le fil d'exécution actuel, mais dans un autre fil.

L'appel d'une fonction asynchrone comme ChartSetInteger à partir du thread principal est rapide car l'exécution réelle a lieu dans un thread différent.


En revanche, l'appel d'une fonction synchrone ChartGetInteger nécessitera la synchronisation des threads, ce qui peut prendre du temps supplémentaire.
Les retards sont particulièrement perceptibles lorsque le thread parallèle met constamment à jour les données de la structure graphique (par exemple, lorsque l'utilisateur déplace la fenêtre du graphique ou fait défiler l'historique).
Le plus souvent, pour des raisons de simplicité et de fiabilité, un seul objet de synchronisation est utilisé pour sa structure de données graphique.
Vous pouvez essayer d'améliorer la vitesse d'exécution en utilisant la "segmentation des données", mais d'un autre côté, vous pouvez maintenant vous heurter à des blocages, à des données insuffisamment mises à jour ou à des ralentissements dans d'autres domaines plus critiques.
En général, il est préférable de ne pas toucher à quelque chose qui fonctionne déjà bien.

C'est exact, pour accélérer le traitement des commandes synchrones il faut changer l'architecture (GUI en particulier), c'est celle qui donne plus de charge/temps en bloquant le graphique pour le rendu.
 
Un comportement intéressant.
Si vous appuyez sur le bouton PrtScr et déplacez la fenêtre du graphique, cela provoque d'horribles retards pouvant aller jusqu'à 5 secondes.
Toutefois, si vous effectuez uniquement une capture d'écran de la fenêtre du programme terminal.exe avec ALT + PrtScr, il n'y a aucun retard.
 
Ilyas:
TERMINAL_GUI_ON/OFF

A en juger par le service VPS intégré, il y a une certaine expérience.

 
Ilyas :

Je vais supposer que le pic est le rendu du commentaire du graphique, sinon, lorsque la file d'attente des graphiques est vide, l'appel à la fonction ChartGetXXX (note, l'appel avec synchronisation) prend 0.13 millisecondes

Non, Ilyas, il semble qu'il n'y ait pas de commentaire sur le graphique. Je vais utiliser les logs et les poster.

Edit : Voici le résultat, aucune interaction avec le graphique ou MT5 ou Windows, après l'avoir exécuté, sauf pour copier les logs. Une seule carte, aucun autre logiciel ne fonctionne sur le système. Le pic est moins important, mais reste très important par rapport à la moyenne. (µs)

2020.06.13 07 : 11 : 25.192 342152 (EURGBP, H1) Nombre = 7440
2020.06.13 07 : 11 : 25.192 342152 (EURGBP, H1) Min = 37
2020.06.13 07 : 11 : 25.192 342152 (EURGBP, H1) Max = 17776
2020.06.13 07 : 11 : 25.192 342152 (EURGBP, H1) Moyenne = 147

Документация по MQL5: Константы, перечисления и структуры / Константы графиков / Свойства графиков
Документация по MQL5: Константы, перечисления и структуры / Константы графиков / Свойства графиков
  • www.mql5.com
Признак отрисовки ценового графика. Если установлено значение false, то отключается отрисовка любых атрибутов ценового графика и устраняются все отступы по краям графика: шкалы времени и цены, строка быстрой навигации, метки событий Календаря, значки сделок, тултипы индикаторов и баров, подокна индикаторов, гистограммы объёмов и т.д. Значение...
 
Alain Verleyen :

Non, Ilyas, il semble qu'il n'y ait aucun commentaire sur le graphique. Je vais utiliser les logs et les poster.

Edit : Voici le résultat, aucune interaction avec le graphique ou MT5 ou Windows, une fois démarré, sauf pour copier les logs. Une seule carte, aucun autre logiciel ne fonctionne sur le système. Le pic est moins important, mais reste très important par rapport à la moyenne. (µs)

2020.06.13 07 : 11 : 25.192 342152 (EURGBP, H1) Nombre = 7440
2020.06.13 07 : 11 : 25.192 342152 (EURGBP, H1) Min = 37
2020.06.13 07 : 11 : 25.192 342152 (EURGBP, H1) Max = 17776
2020.06.13 07 : 11 : 25.192 342152 (EURGBP, H1) Moyenne = 147

Mise à jour :

Le pic maximal est maintenant sérieusement augmenté :

2020.06.13 08 : 18 : 25.187 342152 (EURGBP, H1) Max = 23520
2020.06.13 08 : 18 : 25.187 342152 (EURGBP, H1) Min = 33
2020.06.13 08 : 18 : 25.187 342152 (EURGBP, H1) Max = 81011
2020.06.13 08 : 18 : 25.187 342152 (EURGBP, H1) Moy = 149

 
Alain Verleyen:

Mise à jour :

Le pic maximal est maintenant sérieusement augmenté :

2020.06.13 08 : 18 : 25.187 342152 (EURGBP, H1) Nombre = 23520
2020.06.13 08 : 18 : 25.187 342152 (EURGBP, H1) Min = 33
2020.06.13 08 : 18 : 25.187 342152 (EURGBP, H1) Max = 81011
2020.06.13 08 : 18 : 25.187 342152 (EURGBP, H1) Moyenne = 149

Pour la pureté de l'expérience, ce script doit être exécuté en parallèle dans plusieurs graphiques et plusieurs terminaux. Puis comparez le temps des arrêts.