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
Le seul embarras est le deuxième glissement. Le reste est bien.
Apparemment, le profileur n'est pas adapté à l'accélération de morceaux de code dont la vitesse d'exécution dépasse quelques millisecondes.
L'EA est dans un glissement pendant 30ms et le profileur montre qu'il était dans une fonction avec trois additions et deux multiplications pendant pas moins de 13% !
Et c'est ce que montre b2593.
Il n'y a rien là ! Parce que, en effet, il n'y a rien là. En outre, sur le deuxième rapport, tout est parfaitement clair.
Réglons ça pour nous améliorer, pas pour jurer.
Le profileur montre que pas moins de 13 % du temps était consacré à une fonction comportant trois additions et deux multiplications!
C'est pourquoi je me suis demandé pourquoi l'EA dont le passage complet au OnTick prend en moyenne 3 ms (c'est plein de calculs et de travail avec l'environnement de trading) alors que le profilage supposé à 60% est en "trois additions et deux multiplications". J'ai trouvé ces exemples succincts.
Je veux utiliser un ancien profileur dans MT5, mais je dois faire de telles danses avec les builds. Je n'ai pas encore réussi à le faire fonctionner.
Veuillez m'aider à interpréter les données du profileur à l'aide d'un exemple simple.
Ça ressemble à un tas de bêtises.
J'essaie vraiment de m'y retrouver, mais je n'ai pas encore eu de chance.
J'ai aussi essayé le remplacement de Sleep.
Les valeurs du profileur ne sont toujours pas claires.
Qu'y a-t-il dans le rapport d'appel ?
J'ai l'impression que ce code ne correspond pas au rapport de la capture d'écran.
Êtes-vous sûr de ne pas avoir corrigé le code pendant que le profileur fonctionnait ?
Que contient le rapport d'appel ?
L'impression est que le code donné ne correspond pas au rapport dans la capture d'écran.
Vous êtes sûr que vous n'avez pas corrigé le code pendant que le profileur fonctionnait ?
Non, je ne l'ai pas fait.
J'ai besoin d'aide pour déchiffrer les résultats du profileur.
Veuillez m'aider à déchiffrer les résultats du profileur.
Qu'est-ce qui n'est pas clair ?
J'ai l'habitude de trier par Total CPU, et de voir ce qui ralentit le plus le programme dans son ensemble. Cela peut être utile.
J'ai 5700 commandes dans mon historique, et la première fois que je l'exécute, j'obtiens presque un rapport vide, puis j'obtiens quelque chose comme ceci :
HistoryDealGetInteger (tous les appels ont pris 36%) et HistorySelect (27%) sont les plus gourmands. Viennent ensuite HistoryOrderGetInteger (18%) et global_initialization (9%).
Les 10% restants ont été consacrés au reste du code.
Mais cela n'a pas de sens de regarder les résultats lors d'une exécution unique aussi rapide, je pense.
Qu'est-ce qui n'est pas clair ?
Un problème d'interprétation. Aucune compréhension de ce qui, où et comment ralentit.
J'ai l'habitude de trier par Total CPU, et de voir ce qui ralentit le plus le programme dans son ensemble. Il peut être utile.
J'ai un rapport presque vierge au premier passage avec 5700 commandes dans l'historique, et puis j'ai ceci :
HistoryDealGetInteger (tous les appels ont pris 36%) et HistorySelect (27%) sont les plus gourmands. Viennent ensuite HistoryOrderGetInteger (18%) et global_initialization (9%).
Les 10% restants sont allés au reste du code.
Merci pour votre réponse détaillée. Je ne comprends pas pourquoi les 45% de cordes et le reste n'ont pas été pris en compte ?
Mais il ne sert à rien de regarder les résultats sur une performance unique aussi rapide, imho.
J'ai ajouté une répétition de 20x sur la longue histoire.
29,41% (on ne sait pas pourquoi) est dû à une parenthèse fermante après return. C'est difficile à interpréter.