Flux d'événements. Comment contrôler et rendre l'événement inactif ? (+ résolu) - page 3

Nouveau commentaire
 

Yedelkin:

De même, s'il existe déjà un événement ChartEventdans la file d'attente du programme mql5 ou si cet événement est en cours de traitement, le nouvel événement de ce type n'est pas mis en file d'attente".

Hmm. C'est vraiment mauvais. Théoriquement, cela signifie que si, par exemple, un indicateur et un conseiller expert utilisent les événements indépendamment, il peut y avoir des sauts dans les deux cas.

Dans ce cas, il est inutile d'utiliser l'événement comme un moyen fiable de transférer des données.

C'est dommage.

 
sergeev:

Votre question "à quelle fréquence approximative les événements personnalisés doivent-ils être envoyés pour ne pas déborder de la file d'attente".

Ma réponse sur la première page est "avec la fréquence des appels OnChartEvent".

C'est-à-dire qu'un événement est un OnChartEvent et qu'il ne doit pas y avoir plus de deux événements entre les deux.

C'est tout ce qu'il faut savoir.

Encore une fois, lisez la première page. J'ai montré comment éviter l'accumulation d'événements utilisateur lorsque l'événement terminal est traité au lieu de l'événement utilisateur. C'est aussi simple que cela.

Encore une fois, poliment :) Vous avez résolu votre problème, j'essaie de résoudre le mien, d'un plan différent. En lisant la discussion, je n'ai pas trouvé de réponse à mes questions. Vous n'avez toujours pas répondu à ma question principale (sur l'utilisation de la mémoire) (si vous choisissez de le faire).

Laissez-moi vous expliquer. Je n'ai pas la tâche "de mettre à jour une certaine fonction, mais plus rapidement que ce que MQL suggère en utilisant une minuterie". D'autant plus que c'est une façon si intelligente qui a été suggérée à la fin. Les événements personnalisés provenant de plusieurs graphiques avec une fréquence variable bombardent un graphique séparé contenant un conseiller expert et une fonction de gestion des événements. Par conséquent, le résultat de votre tâche étroitement ciblée(EventChartCustom dans OnChartEvent) ne correspond pas du tout à mon schéma de travail avec les événements personnalisés.

 

Yedelkin:

Pour clarifier. Je n'ai pas la tâche de "faire en sorte qu'une fonction se mette à jour plus rapidement que ce que MQL suggère par timer". Surtout pas d'une manière aussi intelligente, comme suggéré à la fin. Les événements personnalisés provenant de plusieurs graphiques avec une fréquence variable bombardent un graphique séparé contenant un conseiller expert et une fonction de gestion des événements. Par conséquent, le résultat de votre tâche étroitement ciblée(EventChartCustom dans OnChartEvent) ne correspond pas du tout à mon schéma de travail avec les événements personnalisés.

ce n'est pas alambiqué, c'est simple. Si vous êtes incapable de le comprendre, ce n'est pas mon problème. C'est un...

Ce n'est pas dans OnChartEvent, c'est éparpillé dans tout le code. Vous inventez vos propres contraintes étroites sur son fonctionnement. Ça fait deux.

De même, s'il existe déjà un événement ChartEvent dans la file d'attente de mql5-program ou si un tel événement est en cours de traitement, un nouvel événement de ce type ne sera pas placé dans la file d'attente.

Il s'agit soit d'un bogue, soit d'une erreur de documentation, soit de conditions manquantes.

Les événements sont tous mis en file d'attente avec succès et aucun événement n'est rejeté. Sinon, mon sujet ne serait pas apparu.

J'essaie de résoudre mon autre problème
. Quel est l'effet du dépassement de la file d'attente des événements sur la taille de la RAM ? Si la file d'attente des événements s'est avérée débordante, où vont les événements qui ont débordé de la file d'attente ?

Renat et Rosh ont-ils déjà répondu à cette question ?
 
Rosh:

Si un événement est écarté, il n'est tout simplement pas mis en file d'attente. La mémoire ne se développe pas.

Ouf ! C'est la principale chose que je voulais comprendre. Et puisque TheXpert a dit que seulement quelques Mo sont dépensés dans la file d'attente elle-même, il est probable que la fuite de mémoire soit ailleurs... Allons-y avec cette déclaration jusqu'à preuve du contraire.

Rosh:

Si ce genre de problème se produit, les choses vont très mal. Je pense que la file d'attente d'événements trop remplie est le dernier endroit où chercher des problèmes de mémoire.

Oui, j'essaie de chercher partout où je peux.

Mais notez que sur les trois experts disqualifiés, au moins deux travaillaient avec un flux d'événements personnalisé (l'auteur du troisième ne répond pas à la demande). Lizar (qui travaille avec des événements personnalisés) a également une utilisation élevée de la mémoire. Et tol64 a une consommation de mémoire extrêmement faible car les événements utilisateur sont utilisés moins d'une fois par minute, si j'ai bien compris. Il s'avère donc que vous devrez douter de l'efficacité de la mise en œuvre du concept d'événements personnalisés, bon gré mal gré, jusqu'à ce que vous obteniez une réponse exhaustive.

 
Yedelkin:

Mais notez que sur les trois EA disqualifiées, au moins deux travaillaient avec un flux d'événements personnalisés (l'auteur de la troisième ne répond pas à la demande). Lizar (qui travaille avec des événements personnalisés) consomme également beaucoup de mémoire. Et tol64 a une consommation de mémoire extrêmement faible car les événements utilisateur sont utilisés moins d'une fois par minute, si j'ai bien compris. Il s'avère donc que vous devrez douter de l'efficacité de la mise en œuvre du concept d'événements personnalisés, bon gré mal gré, jusqu'à ce que vous obteniez une réponse exhaustive.

Et n'oublions pas que l'EA a obtenu les événements à partir des indicateurs qui ont été exécutés sur de nombreux outils et horizons temporels, environ 80 au total, si je me souviens bien. Chaque indicateur consomme des ressources pour les tampons d'indicateurs, c'est là que le chien est enterré.
 
sergeev:

ce n'est pas compliqué, c'est simple. Si tu ne peux pas le comprendre, ce n'est pas mon problème.

Comme je l'ai compris, j'ai écrit que c'est compliqué. Sinon, je ne l'aurais pas touché.

sergeev:

Ce n'est pas dans OnChartEvent, c'est dans tout le code. Vous inventez vos propres contraintes étroites sur la façon dont ça fonctionne. C'est deux.

Oui, oui, EventChartCustom n'est pas à l'intérieur de OnChartEvent, mais, genre, à l'extérieur. Maintenant, regardez votre propre code :

void OnChartEvent(int iview, int id, long lparam, double dparam, string sparam)
{
    if (id==CHARTEVENT_CUSTOM+VM_IDLE)
    {
      ... 
    }
    EventChartCustom(m_chart, VM_IDLE, (long)event_idle, 0, ""); // отправили событие с указанием последнего счетчика
}

De toute évidence, dans ce code, EventChartCustom n'est pas à l'intérieur deOnChartEvent, et j'ai tout faux :)

sergeev:

c'est soit faux, soit un bug, soit une erreur de documentation, soit une condition sous-estimée.

Tous les événements réussis restent dans la file d'attente et aucun événement n'est écarté. Sinon, mon sujet ne serait pas apparu.

Il existe au moins une autre version : dans votre cas particulier, la file d'attente ne déborde tout simplement pas (en raison de l'efficacité du code), il n'y a donc pas de faits de rejet des événements.

 
Yedelkin:

Il existe au moins une autre version : dans votre cas particulier, la file d'attente ne déborde tout simplement pas (en raison de l'efficacité du code), il n'y a donc aucune preuve de rejet des événements.

Voici le cas particulier que j'ai commencé à démontrer en ne rejetant pas les événements identiques.

https://www.mql5.com/ru/forum/5091#comment_112780

J'y ai écrit pourquoi le débordement se produit.

Oui, oui, EventChartCustom n'est pas à l'intérieur de OnChartEvent, mais, genre, à l'extérieur. Maintenant, regardez votre propre code :

Allez à la racine ! J'ai fait une démonstration du problème et de sa solution. Cet appel à EventChart pourrait se trouver n'importe où dans le code.

 
Rosh:
Et n'oublions pas que le conseiller expert recevait les événements des indicateurs qui étaient exécutés sur de nombreux outils et horizons temporels, environ 80 au total, si je me souviens bien. Chaque indicateur consomme des ressources pour les tampons d'indicateurs, et c'est là que le bât blesse.
Vous parlez des Japonais ? Dans mon cas, c'est plus simple : j'ai un indicateur universel avec 8 ou 15 indicateurs tampons calculés fonctionnant sur 6 instruments à une même période. C'est-à-dire qu'il n'y a que 6 indicateurs. Et, théoriquement, un tel dispositif peut consommer 2 Go en une semaine ?
 
Yedelkin:
Vous parlez des Japonais ? Dans mon cas, c'est plus simple : un indicateur universel avec 8 ou 15 tampons d'indicateur de calcul, fonctionnant sur 6 instruments à une même période. C'est-à-dire qu'il n'y a que 6 indicateurs. Théoriquement, un tel système peut consommer 2 Go en une semaine ?
Lisez l'article Réduire la consommation de mémoire pour les indicateurs auxiliaires, cela peut être utile.
 
Rosh:
Lisez l'article Réduire la consommation de mémoire des indicateurs auxiliaires, cela peut être utile.

Merci, j'y ai déjà tout optimisé :) Y compris avec cet article en tête, autant que je m'en souvienne. Je vais devoir attendre le prochain degré d'illumination :)

Est-il possible de déterminer séparément le conseiller expert et l'indicateur, s'ils fonctionnent ensemble via des événements personnalisés ?

1234567
Nouveau commentaire