Aiuto con OOP - pagina 8
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
Confronto errato, poiché non tiene conto del tempo per la rimozione automatica degli oggetti.
Modificato.
Da dove vengano 123 megabyte dopo la V3 - non lo so.
Domanda: quante volte nel vostro benchmark viene eseguita ogni funzione?
Ho bisogno dell'output di tempo medio, numero di corse e stddev.Domanda: quante volte viene eseguita ogni funzione nel vostro benchmark?
Esattamente una volta.
Il combattimento EA è interessato alle raffiche di lag. Non ho fatto molti esperimenti teorici, quindi non ho fatto una cosa del genere.
Vasiliy Sokolov #:
No, corretto. E questa è una questione di principio. La rimozione automatica non avviene nel flusso principale, dove il costo del tempo è estremamente costoso.
Purtroppo, se si misura all'interno della funzione e all'esterno, i tempi sono diversi. All'interno è più veloce. Cioè la rimozione di oggetti ha un certo effetto. Quindi la versione sull'altro thread è un po' dubbia.
Il secondo punto. Prestare attenzione alla V2. Non c'è cancellazione di oggetti e una perdita di memoria diretta è volutamente permessa. Anche in questo caso ci vogliono 1,4 secondi rispetto a 1,2 secondi nella V1, anche se non c'è affatto tempo per la rimozione.
La mia immagine è l'opposto.
Durante l'esecuzione del programma mql, nessun assemblatore rimuove nulla, né nello stesso thread, né in un altro thread.
Il collettore è nominalmente presente, ma viene eseguito solo quando il modulo è finito. I messaggi sulla memoria persa nel log sono solo il collettore.
Esattamente una volta.
In questo caso, il parametro di riferimento è irrilevante. Almeno non per me.
Non si tratta della mia implementazione. Puoi misurarlo alla vecchia maniera.
Quindi l'altra versione del flusso è un po' dubbia.