![MQL5 - Linguaggio delle strategie di trading integrato nel client terminal MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
L'unico imbarazzo è il secondo scivolone. Il resto va bene.
Apparentemente, il profiler non è adatto allo scopo di velocizzare pezzi di codice che girano più velocemente di qualche millisecondo.
L'EA è in uno slittamento per 30ms e il profiler mostra che era in una funzione con tre aggiunte e due moltiplicazioni per ben il 13%!
E questo è ciò che mostra b2593.
Lì non c'è niente! Perché, in effetti, lì c'è zero. Inoltre, sul secondo rapporto, tutto è abbondantemente chiaro.
Risolviamo il problema per migliorare, non per imprecare.
Il profiler mostra che ben il 13% di esso era in una funzione con tre addizioni e due moltiplicazioni!
Ecco perché mi sono chiesto perché l'EA il cui passaggio completo OnTick richiede in media 3 ms (è pieno di calcoli e di lavoro con l'ambiente di trading) quando la profilazione presumibilmente 60% è in "tre aggiunte e due moltiplicazioni". Ho trovato questi esempi succinti.
Voglio usare un vecchio profilatore in MT5, ma devo fare queste danze con le build. Non sono ancora riuscito ad eseguirlo.
Per favore, aiutatemi a interpretare i dati del profiler con un semplice esempio.
Sembra un sacco di sciocchezze.
Sto davvero cercando di capire come funziona, ma non ho ancora avuto fortuna.
Ho anche provato la sostituzione del sonno.
Ancora non sono chiari i valori del profiler.
Cosa c'è nel rapporto sulle chiamate?
Ho l'impressione che questo codice non corrisponda al rapporto dello screenshot.
Sei sicuro di non aver sistemato il codice mentre il profiler stava lavorando?
Cosa c'è nel rapporto della chiamata?
L'impressione è che il codice dato non corrisponda al rapporto nello screenshot.
Sei sicuro di non aver corretto il codice mentre il profiler era in esecuzione?
No, non l'ho fatto.
Ho bisogno di aiuto per decifrare i risultati del profiler.
Per favore, aiutatemi a decifrare i risultati del profiler.
Cosa non è chiaro?
Di solito ordino per CPU totale, e vedo cosa rallenta di più il programma in generale. Può essere utile.
Ho 5700 ordini nella mia storia, e la prima volta che lo eseguo, ottengo un rapporto quasi vuoto, e poi ottengo qualcosa come questo:
HistoryDealGetInteger (tutte le chiamate hanno preso il 36%) e HistorySelect (27%) mangiano di più. Poi viene HistoryOrderGetInteger (18%) e global_initialization (9%).
Il restante 10% è stato speso per il resto del codice.
Ma non ha senso guardare i risultati durante una singola esecuzione così veloce, imho.
Cosa non è chiaro?
Un problema di interpretazione. Nessuna comprensione di cosa, dove e come sta rallentando.
Di solito ordino per CPU totale, e vedo cosa sta rallentando maggiormente il programma in generale. Può essere utile.
Ho un rapporto quasi vuoto alla prima esecuzione con 5700 ordini nella storia, e poi ho questo:
HistoryDealGetInteger (tutte le chiamate hanno preso il 36%) e HistorySelect (27%) mangiano di più. Poi viene HistoryOrderGetInteger (18%) e global_initialization (9%).
Il restante 10% è andato al resto del codice.
Grazie per la sua risposta dettagliata. Non capisco perché non si è tenuto conto del 45% di corde e del resto?
Ma non ha senso guardare i risultati su una prestazione singola così veloce, imho.
Ho aggiunto una ripetizione 20x sulla storia lunga.
Il 29,41% (non è chiaro perché) è dovuto a una parentesi di chiusura dopo il ritorno. È difficile da interpretare.