Erreurs, bugs, questions - page 2668

[Sergey Dzyublik]

fxsaber:

Je n'avais pas remarqué ça dans le code. Cela s'explique alors, car il n'y a qu'un seul si déclenché, où si la taille n'a pas changé, on sort.

Explication du code ci-dessus#2666

test1, crée tous les éléments en une seule fois lors du premier appel, les autres appels de ArrayResize sont "inactifs".
Le nombre total d'appels ArrayResize == array_size :

      T class_array[];
      for(int i = 1; i <= array_size; i++){
         ArrayResize(class_array, array_size);
      }

test2, crée un élément et réserve de l'espace pour un autre élément de taille_tableau-1, les appels restants à ArrayResize vont créer +1 élément dans le tableau à partir de la mémoire précédemment réservée.
Le nombre total d'appels à ArrayResize == array_size :

      T class_array[];
      ArrayResize(class_array, 1, array_size - 1);
      for(int i = 2; i <= array_size; i++){
         ArrayResize(class_array, i);
      }

* il y avait une erreur dans le code original (+- un élément de différence). Le code a été mis à jour.
La question demeure : pourquoi l'algorithme de test2 est 7 fois plus lent que celui de test1 pour les structures et 2 fois plus lent pour les classes et les int ?

[Alain Verleyen]

Sergey Dzyublik :

De mon côté, la comparaison était ce qu'elle était censée être.
Je sais combien d'éléments seront placés dans le tableau et, au lieu de les créer tous en même temps, je réserve de la mémoire pour les éléments non créés.
Le problème est que si je réserve de la mémoire et que je crée les éléments du tableau un par un, cela prend plusieurs fois plus de temps que si je les crée tous en une seule fois.
Pour les structures, il est donc 7 fois plus lent.
Et il est deux fois plus lent pour les types de données class et int.

Il s'agit d'une très grande différence, que les développeurs peuvent, selon moi, éliminer s'ils le souhaitent.

OK dans ce cas, je suis d'accord pour dire que les frais généraux ne devraient être que plus bas.

Mais je pense que le problème est davantage la façon dont vous comparez. La boucle dans test1 est probablement optimisée et supprimée par le compilateur, et peut-être même ensuite :

 for ( ulong ii= 0 ;ii<count&&! _StopFlag ;ii++)

Essayez le profileur et vous ne verrez qu'une petite différence.

[Alain Verleyen]

Pas d'optimisation du compilateur avec le profileur.

[fxsaber]

Sergey Dzyublik:

La question demeure : pourquoi test2 est-il plus lent que test1 pour les structures par un facteur de 7, et par un facteur de 2 pour les classes et les int ?

Constructeurs par défaut.

[Sergey Dzyublik]

Alain Verleyen:

La boucle dans test1 est probablement optimisée et supprimée par le compilateur.

Si vous exécutez le code#2666 ci-dessus en mode Debug, vous verrez des résultats similaires à ceux obtenus précédemment, car les ralentissements sont causés par le travail de la fonction ArrayResize et non par l'optimisation du code utilisateur.
Le mode débogage est exécuté sans aucune optimisation : ce qui est écrit dans le code est exécuté et ce qui est exécuté n'est que des nop-types pour les points d'arrêt utilisateur sont insérés entre les instructions.

[Aleksei Skrypnev]

Je ne reçois pas de SMS sur le nouveau service confirmant l'ouverture d'un compte de démonstration par SMS. Plus de détails ici.

https://www.mql5.com/ru/forum/334179#comment_1529250

[Alain Verleyen]

Sergey Dzyublik :

Si vous exécutez le code #2666 ci-dessus en mode Debug, vous verrez des résultats similaires à ceux obtenus précédemment, car le décalage se situe dans le travail de la fonction ArrayResize et non dans l'optimisation du code utilisateur.
Le mode débogage est exécuté sans aucune optimisation : ce qui est écrit dans le code est exécuté et ce qui est exécuté n'est que des nop-types pour les points d'arrêt utilisateur sont insérés entre les instructions.

Comme indiqué dans le post #26674, aucun problème avec ArrayResize (), mais seulement avec le test comparatif. Sauf si j'ai raté quelque chose.

[Sergey Dzyublik]

Alain Verleyen:
Comme indiqué dans le post #26674, il n'y a pas de problème avec ArrayResize (), mais seulement avec le test de comparaison. Sauf si j'ai raté quelque chose.

Le problème a été détecté dans le cadre d'un projet réel lors de la recherche d'un goulot d'étranglement pour l'algorithme vector<T>::push_back.
Le problème apparaît dans le cadre de l'exécution lente de ArrayResize en présence de mémoire réservée dans les compilations Release et Debug.

Vous prétendez que tout va bien parce que le profilage n'a rien détecté.
Les résultats obtenus ne dérangent personne.
Cependant, l'absence de problèmes apparents lors du profilage ne les annule pas dans les compilations Release et Debug qui sont utilisées par 100% des utilisateurs.

[Alain Verleyen]

Sergey Dzyublik :

Le problème a été détecté dans le cadre d'un projet réel lors de la recherche d'un goulot d'étranglement pour l'algorithme vector<T>::push_back.
Le problème apparaît dans le cadre de l'exécution lente de ArrayResize en présence de mémoire réservée dans les compilations Release et Debug.

Vous prétendez que tout va bien parce que le profilage n'a rien détecté.
Les résultats obtenus ne dérangent personne.
Cependant, l'absence de problèmes apparents lors du profilage ne les annule pas dans les compilations Release et Debug qui sont utilisées par 100% des utilisateurs.

Je ne peux parler que du code de test que vous avez fourni.

Quoi qu'il en soit, voyons ce que les développeurs ont à dire. Peut-être.

[Artyom Trishkin]

Encore une fois, vingt-cinq...

При соединении с c.mql5.com произошла ошибка. PR_END_OF_FILE_ERROR

Sera-t-il jamais réparé ? Après tout, il tombe plusieurs fois par jour...