Mon approche. Le noyau est le moteur. - page 124
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
Parce qu'au lieu de OrderOpenPrice mettez OrderOpenTime()
Bien. Je me suis mélangé. :)
Je dois admettre que j'ai été un peu surpris par les résultats du test.
C'est pourquoi j'ai voulu que vous fassiez tout vous-même, et non que vous donniez des solutions toutes faites, qui sont comme des pois contre le mur.
J'ai entendu parler des pointeurs vers les fonctions. Mais j'ai très peu de fonctions. C'est pour cette raison que je n'ai pas d'espace et que je dois utiliser la POO.
J'ai un concept de développement différent. Je pense que le fonctionnement de blocs multifonctions holistiques est plus efficace que celui de grands complexes de petites fonctions.
Plus prometteur, du point de vue du développement des mécanismes.
C'est mon opinion...
J'ai plusieurs gros blocs. Pour appliquer la POO, il faut les décomposer en petites fonctions, les organiser en classes, et ensuite, utiliser des pointeurs et d'autres choses.
Mais je ne pourrai pas le faire. Tout simplement parce que je pense différemment.
Le concept de la POO ne coïncide pas avec les particularités de ma façon de penser, et je ne peux pas m'y étendre. C'est la raison.
Notez, Nikolaï, qu'en matière de développement programmatique, je n'ai aucun problème. Tout se développe très rapidement.
En même temps, les mécanismes fonctionnent bien.
J'ai maintenant maîtrisé les unions, et je vois leur application dans une tâche particulière, - l'écriture de chaînes de caractères dans une ressource.
Je vais essayer de vérifier la vitesse et la charge CPU dans l'EA de test et poster le résultat.
Si c'est bon, je vais reconstruire la communication entre le moteur et l'EA, en la faisant sur les ressources.
Afin d'utiliser les ressources pour transmettre des chaînes de longueur indéfinie, ces chaînes doivent être écrites dans un tableau de caractères.
Cependant, il semble que leur taille ne soit déclarée qu'à l'intérieur de l'union et qu'elle ne change pas par la suite.
J'ai essayé de redimensionner le tableau de chars de l'union, par le biais de ArrayResize, mais il n'y a aucun effet.
Il semble que la taille du tableau de caractères doive être définie au préalable. Et il devrait être de taille maximale.
Voici le code :
Il est maintenant clair que la taille du tableau dechars dans l' union doit être connue à l'avance. Parce queArrayResize(u.Char,StrSize) ne le change pas.
Nous devons donc définir la taille du tableau comme étant égale à la longueur de la chaîne maximale...
Bonne nouvelle. Tout fonctionne bien.
La chaîne est écrite dans la ressource et lue par un autre EA sur un autre graphique.
Il n'y a pas de charge sur le processeur. La charge n'est causée que par l'appel de l'Alert qui imprime la chaîne de caractères.
Voici le code des Expert Advisors :
1. Expert Advisor forme la chaîne et l'écrit dans une ressource.
Un conseiller qui lit une ligne d'une ressource sur un autre graphique :
Utilisera les ressources pour la communication. Le seul inconvénient est que vous devez définir la taille maximale du tableau de caractères dans l'union. Mais il n'est pas nécessaire de penser à la taille de la chaîne et au nombre d'objets MT.
Cette méthode est plus lente que la méthode de liaison MT-objet, mais c'est bien.
Votre théorie est intéressante, bien qu'elle ne corresponde pas tout à fait aux résultats de mes expériences, que je vais maintenant poster ci-dessous.
Comme le montre le test, c'est l'initialisation de la matrice de pixels qui sollicite le plus le CPU.
Découvrez l'EA de test ci-dessous.
Relisez la tâche :
Vasiliy Sokolov:
Peter, voici la mission. Créez un panneau montrant les ouvertures d'ordres en cours dans MT4. Il n'est pas nécessaire de faire une copie complète du panneau système, il suffit de créer un tableau simple avec les propriétés de base des ordres ouverts : prix ouvert, direction, profit. Le reste dépend de vous. L'essentiel est que lorsqu'une commande est clôturée, son indication dans votre tableau disparaît également. Et vice versa, elle apparaîtrait dans ce tableau lorsqu'une nouvelle commande est ouverte.
Vous pouvez voir ici les deux opérations nécessaires de redécoupage lorsque le tableau change à l'écran : 1. lors de la fermeture d'une transaction et 2. lors de l'ouverture d'une transaction. Pourquoi redessiner les pixels le reste du temps ?
Est-ce que vous résolvez un autre problème ?
Relisez le problème :
Vasiliy Sokolov:
Nous voyons ici deux opérations de redécoupage nécessaires lorsque le tableau change à l'écran : 1. lors de la fermeture d'une transaction et 2. lors de l'ouverture d'une transaction. Pourquoi redessiner les pixels à d'autres moments ?
Est-ce que vous résolvez un autre problème ?
Eh bien, ils sont redessinés exactement comme vous l'avez dit.
La charge sur le processeur apparaît pendant l'animation:
Il y a une réinitialisation constante des valeurs dans le tableau des pixels. Toutes les 16 millisecondes. Cela charge le processeur jusqu'à 40%.
J'essayais de comprendre ce qu'est exactement la charge. Je pensais que c'était sauvegarder une ressource ou la lire. Il s'est avéré que c'était la réinitialisation du tableau dans la boucle de dessin.
Il s'est également avéré qu'un appel constant de ObjectSetInteger(0, "MT object",OBJPROP_SELECTED,1) ; (toutes les 16 ms) charge également le processeur. D'environ 10 %.
J'utilise cet appel pour dire à un autre EA de lire la ressource avec les données d'animation.
Au total, il obtient +~50% de charge CPU pendant l'animation.