Erreurs, bugs, questions - page 2744

[fxsaber]

Ilyas:

Question d'optimisation. Dans le testeur, à chaque coche, je dois obtenir une coche pour la suite du travail. Je le fais de cette façon.

void OnTick()
{
  static MqlTick Tick;
  
  if (SymbolInfoTick(_Symbol, Tick))
    // ...
}

Il est clair que cette variante sera plus lente :

void OnTick()
{
  MqlTick Tick;
  
  if (SymbolInfoTick(Symbol(), Tick))
    // ...
}

Mais SymbolInfoTick est aussi plus lent parce que son paramètre chaîne n'est pas passé par référence.

Est-il possible d'avoir des surcharges SymbolInfo* régulières où la chaîne est passée par référence ?

C'est mieux d'avoir

const MqlTick _Tick; // Текущий _Symbol-тик.

Dans Optimizer, ces fonctions sont appelées des dizaines de milliards de fois.

[Sergey Dzyublik]

Ilyas:
Suggérez-vous d'ajouter la fonction GetNextEvent ?

Pas vraiment, je préférerais appeler cette fonction comme HandleNextEvent, une signature possible :

bool HandleNextEvent (ENUM_EVENT_TYPE);

Lorsqu'il est appelé, comme GetNextEvent, il vérifie si le ENUM_EVENT_TYPE spécifié est présent dans la file d'attente,
et si cet événement est présent, il transmet automatiquement le contrôle au code utilisateur du gestionnaire correspondant (OnChartEvent, OnTrade, OnTradeTransaction, ...). (mercià fxsaber pour l'ajout)).
Retourne vrai s'il y avait un événement dans la file d'attente, sinon retourne faux.

Cas d'utilisation possible :

//....
for(int i = 0; i < 10^6; ++i){
   // .... Data Calculations

   if((i % 10^3) == 0){
       while(HandleNextEvent(EVENT_TYPE_ALL));
   }
}
//....

[Sergey Dzyublik]

fxsaber:

Question d'optimisation. Dans le testeur, à chaque coche, je dois obtenir une coche pour la suite du travail. Je le fais de cette façon.
Il est clair que cette variante sera plus lente.

Avez-vous vérifié cette affirmation dans la pratique ? Il peut sembler que ce soit tout le contraire.

MqlTick est constitué de types de données primitifs qui ne sont pas initialisés.
Par conséquent, la sélection ne fait pas perdre de temps car il s'agit de la même opération "sub esp", mais d'une taille différente.
Par conséquent, le goulot d'étranglement peut se situer du côté du cache du processeur pour l'opération de lecture d'une valeur de la mémoire.

En général, nous devrions le tester ;))

[fxsaber]

Sergey Dzyublik:

Lorsque cet événement se produit, il transfère automatiquement le contrôle au code utilisateur du gestionnaire approprié.

Cas d'utilisation possible :

Une solution très agréable et utile !

[fxsaber]

Sergey Dzyublik:

Avez-vous testé cette affirmation dans la pratique ? Il se pourrait que ce soit le contraire.

Théorisation ici. Je ne l'ai pas vérifié. Mais le transfert sur le lien de la ficelle semble approprié.

[TheXpert]

Sergey Dzyublik:

Un cas d'utilisation possible :

tu n'as aucun sens.

D'après la signature et votre description, le terminal doit appeler une fonction pour traiter l'événement suivant, puis rendre le contrôle au programme au moment où le handlenextevent est appelé?

Que se passe-t-il si le handlenextevent est appelé à nouveau pendant le traitement ?

Que se passe-t-il avec les événements qui ne passent pas le filtre dans les paramètres ? sont-ils ignorés ? changent-ils de file d'attente ?

Les scripts n'ont pas du tout de file d'attente d'événements, pourquoi en ajouter sur des béquilles alors qu'il existe des conseillers experts et des indicateurs ?

[Sergey Dzyublik]

TheXpert:

1) vous suggérez une sorte d'absurdité.
2) d'après la signature et votre description, le terminal doit appeler le traitement de l'événement suivant par la fonction et ensuite rendre le contrôle au programme au point d'appel du handlenextevent?
3) que se passe-t-il si le handlenextevent est appelé à nouveau pendant le traitement ?
4) et que se passe-t-il pour les événements qui ne tombent pas sous le filtre dans les paramètres ? sont-ils ignorés ? changent-ils l'ordre ?

1) Mon travail consiste à proposer, mais si c'est quelque chose de fou ou non - c'est aux développeurs, pas à vous, ils en savent un peu plus...
2) Très bien. Si je suis intéressé par le traitement d'un événement spécifique, et non de tous les événements du système, il serait agréable de pouvoir traiter uniquement ce type d'événement, en laissant le traitement des autres événements se faire normalement.
3) Si HandleNextEvent est appelé à nouveau pendant le traitement - appelez et traitez. La seule chose qui peut arriver est le débordement de pile, mais c'est le problème de l'utilisateur et du code, pas celui du développeur.
4) Les événements qui ne tombent pas sous le filtre restent dans la même séquence et seront appelés lorsque l'utilisateur rendra le contrôle au système comme d'habitude.

[fxsaber]

TheXpert:

Les scripts n'ont pas du tout de file d'attente d'événements, pourquoi en ajouter sur des béquilles alors qu'il existe des EA et des indicateurs ?

Voici un exemple de script qui ouvre et ferme ses positions/ordres de manière asynchrone.

// Максимально быстро все закрывает. Возврат, когда действие подтверждено.
bool CloseAll()
{
  uint RequestID[];
  
  for (int i = ArrayResize(RequestID, OrdersTotal()) - 1; i >= 0; i--)
    if (OrderSelect(i, SELECT_BY_POS))
      // Отправили асинхронный приказ
      RequestID[i] = (OrderType() <= OP_SELL) ? OrderCloseAsync(OrderTicket(), OrderLots(), OrderClosePrice(), 100) : OrderDeleteAsync(OrderTicket());
  
  return(Transactions.Waiting(RequestID)); // Дождались ответа от сервера на все асинхронные приказы
}

[TheXpert]

Sergey Dzyublik:

1) C'est mon travail de suggérer, et ce n'est pas à vous de décider si c'est un dilemme ou non, mais aux développeurs, ils en savent un peu plus...

Si vous suggérez quelque chose qui est plus facile à mettre en œuvre, il y a une meilleure chance de mise en œuvre. supprimé votre option parce qu'elle ne donne presque rien.

[Ilyas]

fxsaber:

Question d'optimisation. Dans le testeur, à chaque coche, je dois obtenir une coche pour la suite du travail. Je le fais de cette façon.

Il est clair que cette variante sera plus lente :

Mais SymbolInfoTick est aussi plus lent parce que son paramètre chaîne n'est pas passé par référence.

Est-il possible d'avoir une surcharge régulière de SymbolInfo* où la chaîne est passée par référence ?

C'est mieux d'avoir

Dans Optimizer, ces fonctions sont appelées des dizaines de milliards de fois.

L'appel à Symbol() entraîne TOUJOURS l'accès à la variable globale _Symbol, ainsi qu'à Digits(), Point(), Period(), GetLastError(), IsStopped(), UninitializeReason().