MT5 e la velocità in azione - pagina 23
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
Nel caso in cui qualcuno non lo capisca, è la libreria fxsaber che sta causando la frenata quando viene applicata nel codice di qualcun altro.
Invece di sottolinearlo esplicitamente, ha iniziato a fare il gioco della frenata della piattaforma e degli esempi suicidi di scivolamento. E quando c'è stata l'opportunità di arrivare alla vera causa e appianare la questione, non l'ha colta.
Per il bene dell'ottimizzazione locale stava avvelenando la cache della cronologia per l'applicazione principale.Forum sul trading, sistemi di trading automatico e test di strategie di trading
MT5 e la velocità in azione
fxsaber, 2020.09.02 00:02
C'era un codice MQL5 pulito riproducibile da molti. La cronologia del thread prima studio, invece di giocare teoria della cospirazione, che qualcuno ha bisogno di te così tanto che è disposto a spendere il suo tempo su di te per mudsling.
Stai facendo un ottimo lavoro come tacchino. Non c'è stata alcuna discussione di qualsiasi biblioteca qui specificamente nel thread in quanto non è costruttivo.
Il punto è che se qualcuno si avventura a usare librerie condivise in cui il parametro from-input non coincide, avrà dei freni. Non c'è menzione di questo da nessuna parte nella Documentazione. Almeno qualcosa su questo argomento ti è stato estratto con le pinze. E quando è stato fatto, hanno iniziato ad accusarti di imbrogliare.
Questa caratteristica di MQL dovrebbe essere scritta nel ramo Documentazione e nel ramo Caratteristiche. Esegui gli script MQL5 puliti da questo ramo sulle build corrispondenti alle date della loro creazione. A quanto pare, molte correzioni sono state fatte alla cieca, per sicurezza.
Stai facendo un ottimo lavoro come indie. Nessuna biblioteca è stata specificatamente menzionata qui nel thread, perché non è costruttivo.
Perché avete fatto del vostro meglio per non parlare delle vostre biblioteche. In presenza di queste biblioteche. Con la costante opposizione di "il mio è più veloce". Così hai abilmente mascherato l'autoscatto infilando "guarda com'è lento".
Il punto è che se uno osa usare insieme delle librerie in cui il parametro from-input non è lo stesso, otterrà dei ritardi. Non c'è menzione di questo da nessuna parte nella Documentazione. Almeno qualcosa ti è stato tolto con le pinze. E quando è stato fatto, hanno iniziato ad accusarti di imbrogliare.
Questa caratteristica di MQL dovrebbe essere scritta nel ramo Documentazione e nel ramo Caratteristiche. Esegui gli script MQL5 puliti da questo ramo sulle build corrispondenti alle date della loro creazione. A quanto pare, molte correzioni sono state fatte alla cieca, per sicurezza.
La documentazione di HistorySelect dice chiaramente:
Quando lavorate con volumi enormi (e avete mostrato migliaia e decine di migliaia di affari nella storia per una ragione), che richiedono un accesso atomico/snapshot, dovete capire il loro costo.
Tanto più che ho spiegato i dettagli tecnici di queste cache in grande dettaglio in questo thread.
Avete provato per niente a randomizzare ogni campione e ad avvelenare il più possibile la cache? Per il bene della sua posizione qualche autoscatto è in ordine?
Perché hai fatto tutto il possibile per mantenere le tue biblioteche in silenzio. Ecco perché avete abilmente mascherato i bug autoinflitti ostentando "guardate quanto è lento".
Il 99% dei bug si trova in questo modo. Prima il comportamento strano si trova nel grande codice. Poi la localizzazione trova la causa. Ero più preoccupato per i freni.
funzione di trading. I problemi sono quasi ovunque.
La documentazione di HistorySelect afferma esplicitamente:
Mi chiedo chi ha visto qualcosa tra le righe di questo testo? Personalmente, ho capito (prima di questo ramo), che HistoryDealSelect e HistoryOrderSelect devono essere scritti così.
Altrimenti, è garantito che incontrerete dei ritardi.
Quando si lavora con volumi enormi, che richiedono un accesso atomico/snapshot, è necessario capire il loro costo.
Soprattutto perché ho spiegato i dettagli tecnici di queste cache in grande dettaglio in questo thread.
Ho raccolto le informazioni necessarie in questo thread.
Avete provato per niente a randomizzare ogni campione e ad avvelenare il più possibile la cache? Per il bene della sua posizione qualche autoscatto è in ordine?
Potete vedere tutto in ordine cronologico in questo thread. Il problema è stato originariamente mostrato senza randomi.
Questo thread è una grande testimonianza di come si possono distorcere le parole del tuo avversario. Tutte le fonti e i loro risultati sono salvati qui.
Perché il terminale non può semplicemente aumentare la cache quando la storia completa viene richiesta di nuovo, recuperare e mettere in cache l'intervallo mancante? Questo sembrerebbe risolvere il problema. Dopo tutto, quando si richiedono barre/biglietti, vengono restituiti pacchetti di dati mancanti, quindi c'è un meccanismo per questo.
Perché il terminale non può semplicemente aumentare la cache quando la storia completa viene richiesta di nuovo, recuperare e mettere in cache l'intervallo mancante?
Questo è già stato fatto.
Ma se tra HistorySelect( 0, INT_MAX ) chiamaHistorySelect( other_time, ... ), la cache sarà ricostruita a partire da other_time e la prossima richiestaHistorySelect( 0,... ) porterà a una nuova costruzione della cache (sarà più lenta).
Questo è già stato fatto.
Ma se tra le chiamate di HistorySelect( 0, INT_MAX ) chiamiamoHistorySelect( other_time, ... ), la cache sarà ricostruita a partire da other_time e la prossima richiesta diHistorySelect( 0,... ) porterà a una nuova costruzione della cache (sarà più lenta).
Se l'hai fatto, è buono, l'unica questione è poi sulla comodità di lavoro con i dati ricevuti, a condizione che la cache sia costruita.
Non ho capito le operazioni di trading così profondamente, ma se l'intervallo di query cambia, allora non c'è la possibilità di cercare rapidamente i dati all'interno della storia senza una forza bruta completa?
Non sono così addentro al trading, ma se l'intervallo della query cambia, allora non c'è modo di cercare rapidamente i dati all'interno della storia senza un'enumerazione completa?
Che senso ha questa conoscenza se non la usi?
Nessun problema pratico = nessuna domanda.
OrderExist e PositionExist sono funzioni speciali ottimizzate che evitano uno stupido looping di tutti gli ordini o posizioni alla ricerca di voci per simbolo, tipo di transazione e medzhik.
Il risultato è una serie di biglietti.
I programmi possono risparmiare molto denaro utilizzando queste funzioni. Soprattutto quando si chiamano posizioni aperte e ordini in massa, costantemente e ripetutamente in loop di overshoot.
In futuro implementeremo funzioni più efficaci per accedere ai dati commerciali di massa.
Il linguaggio sarà anche drammaticamente rafforzato e semplificato con funzionalità più potenti.
"OrderExist e PositionExist" - non si trovano nella documentazione, dove leggerli?
Molto probabilmente dopo la prossima versione di rilascio (ora in beta)