Mon approche. Le noyau est le moteur. - page 125
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
Ils sont donc redessinés exactement comme vous l'avez dit.
Et la charge sur le processeur provient de 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.
Désolé, je n'ai pas remarqué qu'il ne s'agit plus de la liste des transactions ouvertes. Il a disparu, je pense, de 2-3 pages du fil.
Non, c'est bon. Je viens d'évoquer la charge CPU parce que je vais refaire la communication entre l'EA et le moteur, ce qui signifie que le tableau des transactions ouvertes prendra également des données différemment.
Pourquoi faire le periris 64 images par seconde (16 ms), pour l'oeil est assez 32 images par seconde.
Bonne question. En fait, la minuterie ne fonctionne pas bien. Il y a des sauts. 16,32,16,16...
Si vous utilisez 32, les sauts sont de 64 ms. Et cela se remarque. En outre, diverses autres choses alourdissent et ralentissent le dessin. Par exemple, la file d'attente des événements OnChartEvent().
Je pense que cela affecte la qualité de l'animation. J'ai essayé d'utiliser 25 ms. Puis 16, et j'en suis arrivé à la conclusion que le 16 traduit mieux un mouvement fluide.
Plus tard, le moteur skolnuyu avec l'animation 16 ms et 32 ms et vous verrez par vous-même. Bien que, peut-être que ce sera ok....
Bonne question. En fait, la minuterie ne fonctionne pas bien. Il y a des sauts. 16,32,16,16...
Si vous utilisez 32, les sauts sont de 64 ms. Et cela se remarque. En outre, diverses autres choses alourdissent et ralentissent le dessin. Par exemple, la file d'attente des événements OnChartEvent().
Je pense que cela affecte la qualité de l'animation. J'ai essayé d'utiliser 25 ms. Puis 16, et j'en suis arrivé à la conclusion que le 16 traduit mieux un mouvement fluide.
Plus tard, le moteur skolnuyu avec l'animation 16 ms et 32 ms et vous verrez par vous-même. Bien que, peut-être que ce sera ok....
C'est juste que ce n'est pas vraiment 16ms, mais 1000/64=15.625ms. C'est pourquoi il est préférable de définir 30 ms au lieu de 32 ms, car il y aura moins de sauts. Par exemple, si vous mettez une pause entre les images de 33 ms, la pause réelle sera de 15,625×3=46,875 ms.
Pourquoi ? Simple, intéressant.
Pourquoi ? Simple, je me demande.
C'est juste que ce n'est pas vraiment 16ms, mais 1000/64=15.625ms. C'est pourquoi il est préférable de définir 30 ms au lieu de 32 ms, car il y aura moins de sauts. Par exemple, si vous mettez une pause entre les images de 33 ms, la pause réelle sera de 15,625×3=46,875 ms.
OK, je vais en tenir compte.
Réduire la fréquence de la minuterie permettra certainement de réduire la charge sur le processeur. Si cela ne dégrade pas la qualité de l 'animation, tant mieux. La charge du processeur peut être réduite jusqu'à 30 %, mais elle le sera toujours.
Tu devras t'en accommoder.
Certes, si le dessin est réparti entre différents threads (par exemple, une partie de l'animation dessine l'Expert Advisor, et une partie du moteur), alors la charge serait presque supprimée. Nous devons penser...
Hélas, mon hypothèse ne s'est pas confirmée.
Maintenant j'ai fait une expérience - j'ai mis un EA sur deux graphiques. Le conseiller expert charge le processeur de 50%.
J'ai découvert que même en travaillant avec différents graphiques, la charge du CPU s'additionne et la charge totale du CPU du côté de MT est supérieure à 90%.
Ainsi, même le fait de répartir les graphiques entre différents conseillers experts ne sera d'aucune utilité. La charge s'accumule !
Hélas, mon hypothèse ne s'est pas confirmée.
Maintenant j'ai fait une expérience - j'ai mis un EA sur deux graphiques. Le conseiller expert charge le processeur de 50%.
J'ai découvert que même en travaillant avec différents graphiques, la charge du CPU s'additionne et la charge totale du CPU du côté de MT est supérieure à 90%.
Par conséquent, même le fait de répartir les graphiques entre différents conseillers experts ne sera d'aucune utilité. La charge s'accumule !