Erreurs, bugs, questions - page 977
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
Le texte change dans toutes (la moitié) des étiquettes destinées à afficher la valeur de l'indicateur, et non sa description. Vous pouvez le constater en exécutant le script.
Soit je ne vous comprends pas. De quelle ligne parle-t-on exactement ?
Désolé, je regardais au mauvais endroit depuis mon téléphone portable et j'ai fait une erreur.
Je vais effectuer mes propres tests dans les prochaines heures et poster le code source et les résultats détaillés.
Je veux dire TextOut. N'est-ce pas un système ?
Je comprends l'étiquette, je ne l'associe pas du tout à GDI.
Je croyais qu'avec le GDI, il s'agissait de tags.
La modification des paramètres de l'étiquette n'est rien d'autre qu'un bourrage massif du flux de commandes dans une file d'attente dédiée sans aucun ajout réel de ces données à des objets réels (les objets appartiennent au graphique, pas à MQL5), jusqu'à ce que les données de l'objet soient rendues ou relues. C'est-à-dire que la modification réelle des objets est reportée. Nous avons volontairement appliqué cette optimisation pour permettre aux développeurs de travailler avec des dizaines de milliers d'objets sans ralentissement.
En d'autres termes, lorsque vous modifiez des objets, l'exécution réelle est retardée, ce qui donne une impression de rapidité. Bien et toute la charge du dessin est portée sur le fil d'interface (graphique) de l'application. Et lors du rendu, des méthodes d'optimisation et de coupure des limites de visibilité fonctionnent, ce qui permet de travailler normalement avec 300 000-500 000 objets par graphique.
Mais lorsqu'on travaille avec des bitmaps, tout le travail est fait dans MQL5 en une seule fois, sans aucun délai, mais ensuite il est fait instantanément lors du rendu. Et le temps total "modification + rendu" d'un bitmap est susceptible d'être plus rapide pour un nombre donné d'objets. D'autant plus que le bitmap est sauvegardé entre les appels et que vous ne pouvez dessiner que ce dont vous avez besoin au lieu de reconstruire tout le canevas.
Je vais effectuer des tests détaillés et poster les résultats montrant comment les objets et les bitmaps se comportent dans les différents modes.
J'ai posté les résultats dans un fil de discussion séparé : Test de performance des étiquettes de texte et des bitmaps sur un graphique.
L'auteur avait un sérieux bug dans son script de gestion des bitmaps - en réalité, il utilisait deux bitmaps au lieu d'un et les copiait constamment l'un dans l'autre, ce qui réduisait les performances.
Les résultats du test ont été postés dans un fil de discussion séparé : Test de performance des étiquettes de texte et des bitmaps sur un graphique.
L'auteur avait un sérieux défaut dans son script lorsqu'il travaillait avec des bitmaps - en réalité, il utilisait deux bitmaps au lieu d'un et les copiait constamment l'un dans l'autre, ce qui réduisait les performances.
Donc le moyen d'accélérer la production réelle est un défaut ? :)
J'ai déjà décrit ici l'objectif pour lequel le canevas de modèle et le canevas de travail ont été introduits.
Vivons longtemps.
Le manuel MQL5 indique que le type datetime est https://www.mql5.com/ru/docs/basis/types/integer/datetime :
"Gamme de valeurs du 1er janvier 1970 au 31 décembre 3000. "
en fait la valeur maximale à 32535244799 est 3001.01.01 07:59:59
Pour améliorer la pureté de la programmation, je voudrais interroger le public à ce sujet.
Supposons qu'il existe un drapeau (bool Flag) déclaré globalement. Lorsque certains événements/conditions se produisent, il doit être réglé sur une certaine valeur.
La première variante :
Deuxième option :
Quelle option ?
1. plus rapide en termes de performances ?
2. Si je peux me permettre, "plus professionnel" ?
On suppose que cette section du code sera contrôlée assez souvent, par exemple à chaque tic.
Pour améliorer la pureté de la programmation, je voudrais interroger le public à ce sujet.
Supposons qu'il existe un drapeau (bool Flag) déclaré globalement. Lorsque certains événements/conditions se produisent, il doit être réglé sur une certaine valeur.
Bien sûr, la première option est la plus rapide. Moins d'instructions, mais aussi une comparaison/ramification en moins.
Pour améliorer la pureté de la programmation, je voudrais interroger le public à ce sujet.
Supposons qu'il existe un drapeau (bool Flag) déclaré globalement. Lorsque certains événements/conditions se produisent, il doit être réglé sur une certaine valeur.
La première variante :
Deuxième option :
Quelle option ?
1. plus rapide en termes de performances ?
2. Si je peux me permettre, "plus professionnel" ?
Cette section du code est censée être contrôlée assez souvent, par exemple à chaque tic.
Et à votre avis, chaque tic est fréquent ?
Il y a environ 3 à 5 millions de comparaisons de ce type en une seule fois ; le CPU ne remarquera même pas vos conditions.
Mais si vous comptez comparer plusieurs milliers par tic, cela vaut la peine de l'optimiser.
En général, il existe un profileur pour optimiser la vitesse.