Erreurs, bugs, questions - page 2776
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
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.
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.
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 !
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.
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.
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.
A en juger par le service VPS intégré, il y a une certaine expérience.
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
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
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.