Erreurs, bugs, questions - page 1625
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
Je n'ai pas d'argent pour MT5 - je négocie des comptes en cents et le DC n'est pas pressé de les ouvrir pour cinq cents.
Je voudrais soulever le problème de la lenteur de la compilation de MQL5 une fois de plus. Il y a environ trois mois, j'ai essayé de soulever ce problème, mais il n'a pas été compris, apparemment mes arguments n'étaient pas assez convaincants. Par conséquent, je suis revenu à l'ancienne version (1159), qui a tout compilé presque instantanément (alors qu'avec les nouveaux compilateurs, mon projet a compilé en 20 secondes).
Et donc, il y a une semaine, j'ai essayé de passer à une nouvelle version. Je me suis dit "oubliez les 20 secondes, je vais faire avec pour avoir de nouvelles choses". Bien sûr, j'ai dû modifier un peu le code pour me conformer aux nouvelles conditions, ce qui a révélé plusieurs bugs du nouveau compilateur (décrits ici).Le résultat est que mon projet compile depuis 30 secondes déjà ! Je ne sais pas si cela a à voir avec la complication du projet ou avec une "complication" de plus du compilateur, mais cela ne colle plus.
Le projet contient environ 700 Kb de code source, c'est un Expert Advisor contenant quelques dizaines de mqh. Tout est OOP. Les gens m'ont écrit plus tôt que le ralentissement est probablement causé par de grandes fonctions. J'en avais quelques-uns. Je les ai fragmentés en plus petits morceaux et ils n'ont aucun effet.
Le plus étonnant, c'est que cette super longue compilation ne sert à rien. La vitesse du programme est la même qu'avec l'ancien compilateur, je l'ai mesurée spécifiquement. Cela ne demande qu'une seule phrase : "Pour quoi faire ?".
J'ai la forte impression qu'il y a un bug/dysfonctionnement dans le compilateur à cause duquel il fait une course folle dans un espace vide. Comment expliquer autrement le fait qu'un script absolument vide avec seulement la fonction OnStart() { } compile plus de 400 ms !Il est inimaginable qu'il faille autant de temps pour compiler/optimiser un script vide. Eh bien, en y ajoutant de petites fonctions et classes, vous pouvez voir à quel point le temps de compilation augmente rapidement.
Je tiens à dire tout de suite que mon matériel est bien sûr loin d'être puissant - Core i5U. Mais cela n'empêche pas mon projet de compiler en 1-2 secondes sur un vieux compilateur. Respectivement, le dummy y est compilé en un instant.
Je note aussi. Le compilateur est complètement dépourvu non seulement de la mise en cache des fragments compilés précédemment mais même d'une vérification triviale pour s'assurer que le code source était identique. C'est-à-dire que vous compilez votre projet puis cliquez à nouveau sur le bouton "Compiler" sans faire aucune modification et attendez à nouveau les mêmes 30 secondes. Comment est-ce...
J'aimerais entendre les commentaires des développeurs de MT et des utilisateurs du forum, qui travaillent sur de grands projets (est-ce que je suis le seul à avoir ce problème ?), combien de temps il faut pour compiler, etc. Il faut dire tout de suite que nous parlons de la compilation d'un exécutable.
Mes projets ont plus d'une douzaine de fichiers sources, comme le vôtre, et tous sur la POO, alors que je ne prétendrai pas à 20 secondes, mais plus de 11 - 14 secondes que je vois constamment. Pourtant, une sorte de mise en cache a lieu, puisque si vous ne changez rien, le temps change de 1 à 2 secondes dans une direction imprévisible. Je ne compare pas la construction des projets utilisant l'ancien et le nouveau compilateur, car l'ancien compilateur construisait tout beaucoup plus rapidement. Je pense que les développeurs eux-mêmes voient ce point et qu'un jour ils le corrigeront :) Ce n'est pas pour rien qu'ils sortent plusieurs nouvelles séries chaque mois - cela signifie qu'ils voient quelque chose et le corrigent.
Version du terminal et débit binaire
v.1375, 64 bits
Description du problème.
Après la mise à niveau vers la dernière version, les agents se bloquent après avoir passé les 1900-2100 premières passes pendant l'optimisation. Tout allait bien avant la mise à jour, tous les paramètres et le code EA sont les mêmes.
Séquence d'actions
L'optimisation commence. Courtier en ouverture. Compte réel. Les outils : Si Splice, Vtb Splice, Si 9.16, Vtb 9.16 (je n'ai pas essayé les autres). Intervalle : mensuel, minute, 15 minutes. Prix d'ouverture ou OHLC.
Résultat.
Les agents locaux et distants, après 2000 passages, se figent, les charges CPU, changent d'environ 0,01% par 10 minutes. 14 agents.
Résultat attendu
Marche à suivre pour l'optimisation, comme pour la version précédente.
Informations complémentaires
A propos de moi : programmeur expérimenté .net MQL5
Cependant, une certaine mise en cache est en cours, car si vous ne changez rien, l'heure change de 1 à 2 secondes dans une direction imprévisible.
:) c'est évidemment une erreur, l'influence d'autres processus dans le système, plus le cache disque. De toute façon, 10-15% n'est pas du tout les indicateurs, pour lesquels le cache est fait.
Je ne comparerais pas la construction de projets avec les anciens et les nouveaux compilateurs, car les anciens compilateurs construisaient tout beaucoup plus rapidement. Je pense que les développeurs voient ce point eux-mêmes et le corrigeront à un moment donné :) Ce n'est pas pour rien que plusieurs nouvelles séries sont publiées chaque mois, cela signifie qu'ils voient quelque chose et le corrigent.
Les nouvelles versions bêta sont publiées parce que les gens se plaignent de divers bugs, mais si les bugs sont un argument solide pour qu'ils les corrigent, tout le reste ... Vous devez les convaincre pendant longtemps. Même lorsqu'il semblerait que tous les arguments aient été clairement apportés, que le tableau soit aussi clair que possible, ils résistent toujours, par tous les moyens :) Je suis ici le même qu'il y a 3 mois, j'ai essayé de les convaincre, mais personne n'a soutenu.
Et j'ai constaté que seules quelques personnes utilisent le MQL pour les grands projets et qu'elles ne se soucient probablement pas des petits projets pour quelques secondes supplémentaires.
Au fait, quel type de CPU avez-vous ?
... ils vont faire tout ce qu'ils peuvent :)
Je n'ai pas regardé assez fort. https://www.mql5.com/ru/forum/88768/page2#comment_2587760
Version du terminal et débit binaire
v.1375, 64 bits
Description du problème.
Après la mise à niveau vers la dernière version, les agents se bloquent après avoir passé les 1900-2100 premières passes pendant l'optimisation. Tout allait bien avant la mise à jour, tous les paramètres et le code EA sont les mêmes.
Séquence d'actions
L'optimisation commence. Courtier en ouverture. Compte réel. Les outils : Si Splice, Vtb Splice, Si 9.16, Vtb 9.16 (je n'ai pas essayé les autres). Intervalle : mensuel, minute, 15 minutes. Prix d'ouverture ou OHLC.
Résultat.
Les agents locaux et distants, après 2000 passages, se figent, les charges CPU, changent d'environ 0,01% par 10 minutes. 14 agents.
Résultat attendu
Marche à suivre pour l'optimisation, comme pour la version précédente.
Informations complémentaires
A propos de moi : programmeur expérimenté .net MQL5
Ce comportement se produit-il avec n'importe quel conseiller expert ?
Ce serait bien d'avoir les registres. Veuillez soumettre un ticket au Service Desk.
Les journaux du terminal sont bons, mais les journaux du testeur de stratégie et des agents de test sont plus intéressants.
+ joindre à votre ticket au moins l'EX5 de votre Expert Advisor (nous le supprimerons après la recherche) + description des paramètres utilisés lors de l'optimisation.
Ce comportement est-il observé chez un expert ?
Les journaux seraient utiles, cependant. Envoyez un ticket à Servicedesk.