Errori, bug, domande - pagina 2776
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
Questo non è un errore, è il costo di un comando di sincronizzazione di un grafico
Perché c'è bisogno di un comando a un grafico per togliere le caratteristiche da esso? Non c'è solo una tabella delle caratteristiche di tutti i grafici in memoria, dalla quale si possono semplicemente prendere dati in nanosecondi invece che in millisecondi (nemmeno in microsecondi!)
È chiaro che le funzioni ChartSetInteger, ChartSetDouble, ChartSetString sono asincrone.
Ma perché le funzioni ChartGetInteger, ChartGetDouble, ChartGetString si comportano come asincrone in termini di velocità di esecuzione quando sono sincrone?
Se tale tabella non esiste in memoria e queste funzioni devono rallentare il grafico ogni volta per generare il parametro richiesto, allora non capisco nulla.
Non è costoso avere una tale tabella e tenerla aggiornata. Realisticamente pochi kilobyte in memoria e una piccola frazione di microsecondo per aggiornare la tabella quando le caratteristiche del grafico cambiano.
Ilyas, per favore dimmi, cosa mi manca?
Ma perché allora le funzioni ChartGetInteger, ChartGetDouble, ChartGetString si comportano asincrone in termini di velocità di esecuzione, quando sono sincrone?
Lei ha una sorta di comprensione errata dei termini asincrono e sincrono.
Quando si dice che una funzione è asincrona, significa che sarà eseguita non nel thread di esecuzione corrente ma in qualche altro thread - uno parallelo.
La funzione è asincrona - significa che la funzione non aspetta l'esecuzione del comando accodato con successo nel grafico specificato, ma restituisce immediatamente il controllo.
La proprietà cambierà solo dopo che il comando è stato elaborato nella coda del grafico. LafunzioneChartRedrawdeve essere chiamata per eseguire immediatamente i comandi nella coda del grafico.
Chiamare la funzione asincrona come ChartSetInteger dal thread principale è veloce perché l'esecuzione effettiva avviene in un altro thread.
D'altra parte, chiamare la funzione sincrona ChartGetInteger richiederà la sincronizzazione dei thread e questo potrebbe richiedere del tempo aggiuntivo.
Il ritardo è particolarmente evidente quando il thread parallelo aggiorna costantemente i dati della struttura del grafico (per esempio, quando l'utente sposta la finestra del grafico o scorre la cronologia).
Molto probabilmente, per semplicità e affidabilità, viene usato un unico oggetto di sincronizzazione per la sua struttura di dati del grafico.
Si può cercare di migliorare la velocità di esecuzione usando la "segmentazione dei dati", ma d'altra parte ora si può incorrere in deadlock, o dati sotto-aggiornati, o rallentamenti in altre aree più critiche.
In generale, è meglio non toccare qualcosa che già funziona bene.
Lei ha una certa incomprensione dei termini asincrono e sincrono.
Quando si dice che una funzione è asincrona, significa che sarà eseguita non nel thread di esecuzione corrente, ma in qualche altro thread.
Chiamare una funzione asincrona come ChartSetInteger dal thread principale è veloce perché l'esecuzione effettiva avviene in un thread diverso.
D'altra parte, una chiamata di una funzione sincrona ChartGetInteger richiederà la sincronizzazione dei thread e questo può richiedere tempo aggiuntivo.
Il ritardo è particolarmente evidente quando il thread parallelo aggiorna costantemente i dati della struttura del grafico (per esempio, quando l'utente sposta la finestra del grafico o scorre la cronologia).
Molto probabilmente, per semplicità e affidabilità, un oggetto di sincronizzazione è usato per la sua struttura di dati del grafico.
Si può cercare di migliorare la velocità di esecuzione usando la "segmentazione dei dati", ma d'altra parte ora si può incorrere in deadlock, o dati sotto-aggiornati, o rallentamenti in altri luoghi più critici.
Tutto sommato, è meglio non toccare qualcosa che funziona già in modo stabile.
Hai ragione, ma sembra che ci siano dei colli di bottiglia. Il mercato è ora chiuso, ho eseguito il codice qui sotto su 1 grafico, nient'altro funziona. È in esecuzione su un VPS con solo MT5 in esecuzione e non ho interagito con il grafico / MT5 con qualcosa di diverso da uno screenshot. Tempo in µs, 127 µs in media, ma il picco è di 43.995 µs.
Signori sviluppatori!
Per favore correggetemi se ho scritto nel thread sbagliato. Ci sono suggerimenti per la facilità d'uso e il debug, che penso saranno utili per molti, e per me sono importanti.
1. Aumentare la lunghezza della linea OBJPROP_TOOLTIP per gli oggetti (2 volte è sufficiente). Per le strategie con molta grafica, la lunghezza attuale è molto breve. Per il debug, bisogna spendere del tempo ogni volta per inserire tutti i dati necessari. Poi devi cambiare e/o aggiungere riduzioni per i consumatori su base regolare.
2. Aumentate la lunghezza dei commenti ai nomi dei parametri di input (2 volte è sufficiente). I commenti ai parametri di input sono necessari per il consumatore. E se c'è un grande numero, è anche conveniente fare una numerazione supplementare. Per l'ottimizzazione, è importante conoscere il nome della variabile. Di conseguenza, spesso non è possibile inserire tutto nella lunghezza attuale. Esempio:
3. Diversificare la selezione delle colonne nella tabella dei risultati dell'ottimizzazione - fino alla visualizzazione di tutte le colonne diENUM_STATISTICS e lasciare che l'utente scelga ciò di cui ha bisogno. Questa è una sceltamolto povera per l'analisi. Il drawdown in % è inutile durante l'ottimizzazione con un volume fisso. Non c'è la possibilità di scegliere il massimo prelievo in termini di valuta e deposito. A volte c'è una forte distorsione tra le posizioni di acquisto e di vendita durante l'ottimizzazione, ma è possibile conoscerla solo dopo aver eseguito un singolo test. Spesso dobbiamo inserire i parametri mancanti nel campo del risultato(STAT_CUSTOM_ONTESTER). Ma vogliamo visualizzare ulteriori criteri di risultato lì, ed è possibile visualizzarne solo uno, cosa che potremmo ancora sopportare, se avessimo variato il numero di colonne dei criteri standard daENUM_STATISTICS. Tutto sommato, devo dedicare molto tempo in più all'ottimizzazione e all'analisi.
Grazie!
Hai ragione, ma sembra che ci siano dei colli di bottiglia. Il mercato è ora chiuso, ho eseguito il codice seguente su 1 grafico, nient'altro funziona. È in esecuzione su un VPS con solo MT5 in esecuzione, e non ho interagito con il grafico / MT5 con qualcosa di diverso da uno screenshot. I tempi sono in µs, 127 µs in media, ma il picco è di 43.995 µs.
Suppongo che il picco sia il rendering del commento del grafico, altrimenti, quando la coda del grafico è vuota, la chiamata alla funzione ChartGetXXX (notare la chiamata con sincronizzazione) richiede 0,13 millisecondi
Lei ha una certa incomprensione dei termini asincrono e sincrono.
Quando si dice che una funzione è asincrona, significa che sarà eseguita non nel thread di esecuzione corrente, ma in qualche altro thread.
Chiamare una funzione asincrona come ChartSetInteger dal thread principale è veloce perché l'esecuzione effettiva avviene in un thread diverso.
D'altra parte, una chiamata di una funzione sincrona ChartGetInteger richiederà la sincronizzazione dei thread e questo può richiedere tempo aggiuntivo.
I ritardi sono particolarmente evidenti quando il thread parallelo aggiorna costantemente i dati della struttura del grafico (per esempio, quando l'utente sposta la finestra del grafico o scorre la storia).
Molto probabilmente, per semplicità e affidabilità, viene utilizzato un unico oggetto di sincronizzazione per la sua struttura di dati del grafico.
Si può cercare di migliorare la velocità di esecuzione usando la "segmentazione dei dati", ma d'altra parte ora si può incorrere in deadlock, o dati sotto-aggiornati, o rallentamenti in altre aree più critiche.
In generale, è meglio non toccare qualcosa che già funziona bene.
Se premete il pulsante PrtScr e spostate la finestra del grafico, questo provoca orribili ritardi fino a 5 secondi.
Tuttavia, se si fa solo uno screenshot della finestra del programma terminal.exe con ALT + PrtScr, non c'è alcun ritardo.
A giudicare dal servizio VPS integrato, c'è una certa esperienza.
Presumo che il picco sia il rendering del commento del grafico, altrimenti, quando la coda del grafico è vuota, la chiamata alla funzione ChartGetXXX (nota, la chiamata con sincronizzazione) richiede 0,13 millisecondi
No, Ilyas, sembra che non ci sia nessun commento grafico. Userò i registri e li posterò.
Edit: Ecco il risultato, nessuna interazione con il grafico o MT5 o Windows, dopo averlo eseguito, tranne che per copiare i log. Solo 1 grafico, nessun altro software in esecuzione sul sistema. Il picco è minore, ma ancora molto importante rispetto alla media. (µs)
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Numero = 7440
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Min = 37
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Max = 17776
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Avg = 147
No, Ilyas, sembra che non ci siano commenti sul grafico. Userò i registri e li posterò.
Edit: Ecco il risultato, nessuna interazione con il grafico o MT5 o Windows, una volta avviato, tranne che per copiare i log. Solo 1 grafico, nessun altro software in esecuzione sul sistema. Il picco è minore, ma ancora molto importante rispetto alla media. (µs)
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Numero = 7440
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Min = 37
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Max = 17776
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Avg = 147
Aggiornamento:
Picco massimo ora seriamente aumentato:
2020.06.13 08: 18: 25.187 342152 (EURGBP, H1) Max = 23520
2020.06.13 08: 18: 25.187 342152 (EURGBP, H1) Min = 33
2020.06.13 08: 18: 25.187 342152 (EURGBP, H1) Max = 81011
2020.06.13 08: 18: 25.187 342152 (EURGBP, H1) Avg = 149