Caractéristiques du langage mql5, subtilités et techniques - page 49

Nouveau commentaire
 
fxsaber:

Si vous appuyez sur TAB immédiatement après les mots if, else, while, for, do, il y a une petite construction supplémentaire...


f*cking hell... super, après 5 ans de connaissance de mql - je l'ai découvert.

 

Conclusions d'une conversation dans le SD sur un problème soulevé.

Il s'avère que l'affectation d'une valeur à une variable de type chaîne de caractères est une opération TRÈS coûteuse.

Si cher qu'il est souhaitable de l'éviter si possible, jusqu'à ce que les développeurs améliorent ce point dans le compilateur, ce qui ne semble pas près d'arriver.


À titre d'exemple, si vous effectuez une exécution en ticks réels pendant un mois sur FIBO, cela représente environ 1 million de ticks. Si vous obtenez la valeur de PositionGetString à chaque tick et la comparez à quelque chose, les performances seraient acceptables, mais si vous affectez d'abord le résultat de la fonction à une variable de type chaîne avant de le comparer, la durée de l'exécution augmenterait d'environ une seconde.


Si cela semble être une petite chose, c'est une vision erronée. Lorsqu'un tel EA est exécuté en mode optimisation pour plusieurs milliers de passages, cette seconde supplémentaire se traduit par des heures d'attente supplémentaires. Par exemple, une affectation de chaîne de caractères anodine peut entraîner des heures d'attente supplémentaires pendant l'optimisation. Soyez prudent et tenez compte de cette nuance.


Dans kodobase, il existe un petit outil qui vous permet de détecter de telles défaillances dans différentes implémentations de la même logique de négociation. Écrire du code rapide.

 
fxsaber:

Conclusions d'une conversation dans le SD sur un problème soulevé.

Il s'avère que l'affectation d'une valeur à une variable de type chaîne de caractères est une opération TRÈS coûteuse.

Si coûteux qu'il est souhaitable de l'éviter autant que possible jusqu'à ce que les développeurs améliorent ce point dans le compilateur, ce qui semble être un long chemin.


À titre d'exemple, si vous effectuez une exécution en ticks réels pendant un mois sur FIBO, cela représente environ 1 million de ticks. Si vous obtenez la valeur de PositionGetString à chaque tick et la comparez à quelque chose, les performances seraient acceptables, mais si vous affectez d'abord le résultat de la fonction à une variable de type chaîne avant de le comparer, la durée de l'exécution augmenterait d'environ une seconde.


Si cela semble être une petite chose, c'est une vision erronée. Lorsqu'un tel EA est exécuté en mode optimisation pour plusieurs milliers de passages, cette seconde supplémentaire se traduit par des heures d'attente supplémentaires. Par exemple, une affectation de chaîne de caractères anodine peut entraîner des heures d'attente supplémentaires pendant l'optimisation. Soyez prudent et tenez compte de cette nuance.


Dans kodobase, il existe un petit outil qui vous permet de détecter de telles défaillances dans différentes implémentations de la même logique de négociation. Écrivez un code rapide.

Merci, je ne pensais pas que c'était possible. J'en tiendrai compte dans les développements futurs

 

Une simple devinette pour s'endormir, pourquoi les résultats jaunes ?

struct INT
{
  int Array[];
  
  INT()
  {
    Print(__FUNCTION__); // до сюда не дойдет
  }
};

void OnStart()
{
  INT i = {0};
  
  Print(ArrayResize(i.Array, 5)); // -1
}
 
fxsaber:

Une simple devinette pour s'endormir, pourquoi les résultats jaunes ?

Parce que la structure est remplie de zéros, pas par constructeur, donc la structure du tableau est initialisée incorrectement, arrayresize n'aime pas de tels tableaux, mon code s'est écrasé sur un tel redimensionnement.
 
Combinateur:
Parce que la structure est remplie de zéros, pas le constructeur, donc la structure du tableau est initialisée incorrectement, arrayresize n'aime pas de tels tableaux, mon code s'est planté sur un tel redimensionnement.

C'est une bonne chose que tout le monde le sache.

 
Slava:

Il fait référence à GetMicrosecondCount. Il n'y a pas de moyen précis de savoir si cela ralentit le serveur. Elle peut avoir un effet indirect. Par conséquent, il est préférable d'utiliser la fonction native GetTickCount du système.

GetMicrosecondCount est utilisé pour mesurer les courtes périodes d'exécution du code. Pour mesurer un grand nombre d'exécutions OnTick, il est préférable d'utiliser GetTickCount.

Essayez d'utiliser GetMicrosecondsCount au lieu de GetTickCount lorsque vous obtenez des résultats stables. Vous m'en parlerez ici. Peut-être que je m'inquiète trop à ce sujet.

Votre hypothèse s'est avérée correcte, un appel multiple de GetMicrosecondsCount provoque des décalages terribles dans le testeur. Cependant, GetTickCount a le même effet.
 
fxsaber:

Conclusions d'une conversation dans le SD sur un problème soulevé.

Il s'avère que l'affectation d'une valeur à une variable de type chaîne de caractères est une opération TRÈS coûteuse.

Si cher qu'il est souhaitable de l'éviter si possible jusqu'à ce que les développeurs améliorent ce point dans le compilateur, ce qui ne semble pas près d'arriver.


À titre d'exemple, si vous effectuez une exécution en ticks réels pendant un mois sur FIBO, cela représente environ 1 million de ticks. Si vous obtenez la valeur de PositionGetString à chaque tick et la comparez à quelque chose, les performances seraient acceptables, mais si vous affectez d'abord le résultat de la fonction à une variable de type chaîne avant de le comparer, la durée de l'exécution augmenterait d'environ une seconde.


Si cela semble être une petite chose, c'est une vision erronée. Lorsqu'un tel EA est exécuté en mode optimisation pour plusieurs milliers de passages, cette seconde supplémentaire se traduit par des heures d'attente supplémentaires. Par exemple, une affectation de chaîne de caractères anodine peut entraîner des heures d'attente supplémentaires pendant l'optimisation. Soyez prudent et tenez compte de cette nuance.


Dans kodobase, il existe un petit outil qui vous permet de détecter de telles défaillances dans différentes implémentations de la même logique de négociation. Écrivez un code rapide.

struct STRUCT
{
  string Str;
  
  string Get() const { return(this.Str); }
};

void OnStart()
{
  STRUCT Struct;
  
  Print(Struct.Str);
  Print(Struct.Get()); // Выполняется гораздо дольше, чем предыдущая строка
}
 
fxsaber:

Il s'avère que l'affectation d'une valeur à une variable de type chaîne est une opération TRÈS coûteuse.

...

Si vous affectez d'abord le résultat d'une fonction à une variable de type chaîne avant de le comparer, puis si vous le comparez, le temps d'exécution augmentera d'environ une seconde.

De mon point de vue, le problème n'est pas tant l'affectation coûteuse, mais le fait que le compilateur ne supprime pas cette affectation inutile du code pour une raison quelconque, alors qu'il le devrait. Autrement dit, le code compilé doit être le même dans les deux cas.
 
Alexey Navoykov:
Si je comprends bien, le problème n'est pas tant l'affectation coûteuse, mais le fait que le compilateur ne supprime pas cette affectation inutile du code pour une raison quelconque, alors qu'il le devrait. C'est-à-dire que le code compilé doit être le même dans les deux cas.

Il s'agit d'un problème mineur. Oui, l'optimiseur du compilateur ne sait pas encore comment optimiser de tels moments de chaîne. Mais c'est dans l'affectation des chaînes de caractères que réside le problème de ralentissement.

Écrire du code qui ne peut pas être optimisé par le compilateur et, en même temps, y faire des affectations. Et vous verrez ce qu'est un ralentissement.

L'exemple de la lecture d'un champ de chaîne d'une structure par le biais d'une fonction est exactement la manière dont la lecture des propriétés de position est mise en œuvre dans MT4/5.

Dans MT4, le même OrderSymbol() est freiné s'il est implémenté dans MT5. Les développeurs eux-mêmes essaient de transmettre à leurs fonctions des chaînes de caractères via des liens.

Par conséquent, si vous écrivez quelque chose comme ceci

if ((OrderSymbol() == Symb) && (OrderMagicNumber == Magic))

il est toujours préférable de placer la condition OrderSymbol() à la fin de la condition générale.


J'ai remarqué un ralentissement apparent sur des surfaces apparemment lisses lorsque j'utilise TesterBench.

1...424344454647484950515253545556...247
Nouveau commentaire
Raison: