È possibile evitare molti "o" (||) nelle condizioni che causano la stessa azione? - pagina 6
![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
borilunad, qualsiasi chiamata di funzione aggiunge una frenata inutile. Pertanto, se è richiesta la massima velocità, dovreste sbarazzarvi di tutte le Request(), che eseguono operazioni di una sola sillaba. Lo stesso vale per i cicli. Controllare le condizioni in un ciclo è sempre molto più lento di una semplice serie di if() annidati
Quindi anche le condizioni mutuamente esclusive sono migliori con l'azione if(A || B || C || D);
Ma non posso evitare le chiamate di funzione, perché ho bisogno di controllare molti dati in quel punto, che sono inclusi in quelle condizioni.
Continuerò i miei esperimenti, forse ne ricaverò qualcosa. Ma non c'è controllo sulla diffusione! :)
Tuttavia, un'altra linearesult=false dovrebbe essere meglio combinata con la prima, non influenzerà la velocità.In generale, se A, B, C e D contengono condizioni semplici (con un minimo di aritmetica, senza chiamare tutte le funzioni matematiche e altre cose), allora non si otterrà un gran guadagno di prestazioni da tale ottimizzazione (a meno che questa costruzione non venga eseguita decine di milioni di volte, ovviamente). Ma il sovraccarico di codice può essere significativo.
Ho scritto in uno dei thread che tutto deve essere gestito razionalmente. Per qualche motivo, mi sembra che il tuo codice sia pieno di posti più importanti l'ottimizzazione dei quali darebbe davvero un enorme guadagno di prestazioni. Dovresti iniziare con l'algoritmo di base. La maggior parte dei neofiti hanno un controllo stupido di tutte le condizioni riguardanti TS o ordini aperti ad ogni tick. Ma nella maggior parte dei casi, è sufficiente controllare solo le condizioni limite, per esempio quando l'haul o il low raggiunge un certo valore, o quando appare una nuova barra. Solo dopo si possono eseguire ulteriori controlli.
Beh, oltre ai calcoli ad alta intensità di risorse, dovete pensare a spostare questi calcoli in una DLL. Altrimenti, sedersi e aspettare per 13 minuti nel fottuto MQL4 (mentre si può ottenere lo stesso risultato per 2-3 minuti) sembra essere spiacevole :)
In generale, l'opzione più veloce sarebbe questa:
Tuttavia, un'altra linearesult=false dovrebbe essere meglio combinata con la prima, non influenzerà la velocità.In generale, se A, B, C e D contengono condizioni semplici (con un minimo di aritmetica, senza chiamate di tutte le funzioni matematiche e altre cose), allora non otterrete un gran guadagno di prestazioni da tale ottimizzazione (a meno che questa costruzione non venga eseguita decine di milioni di volte, ovviamente). Ma il sovraccarico di codice può essere significativo.
Ho scritto in uno dei thread che tutto deve essere gestito razionalmente. Per qualche motivo, mi sembra che il tuo codice sia pieno di posti più importanti l'ottimizzazione dei quali darebbe davvero un enorme guadagno di prestazioni. Dovresti iniziare con l'algoritmo di base. La maggior parte dei neofiti hanno un controllo stupido di tutte le condizioni riguardanti TS o ordini aperti ad ogni tick. Ma nella maggior parte dei casi, è sufficiente controllare solo le condizioni limite, per esempio quando l'haul o il low raggiunge un certo valore, o quando appare una nuova barra. Solo dopo si possono eseguire ulteriori controlli.
Beh, oltre ai calcoli ad alta intensità di risorse, dovete pensare a spostare questi calcoli in una DLL. Altrimenti, sedersi e aspettare per 13 minuti nel fottuto MQL4 (mentre si può ottenere lo stesso risultato per 2-3 minuti) sembra essere spiacevole :)
L'opzione più veloce è stata suggerita da Paco
Pensi davvero che sia più veloce sommare più valori ogni volta (cioè eseguire operazioni aritmetiche extra)? Nella mia variante il controllo è finito alla prima partita, mentre nella variante menzionata da te - solo dopo aver sommato tutti i valori e poi controllato la somma.
Inoltre, questa variante richiede il calcolo di TUTTE le condizioni in anticipo. Quindi di che tipo di velocità stiamo parlando? È l'opzione più lenta.
Se volete accelerare, potete provare le operazioni bitwise.
Cioè rendere tutte le variabili di tipo int (false=0). Allora bitwise A|B|C...>0
Se volete accelerare, potete provare le operazioni bitwise.
Cioè rendere tutte le variabili di tipo int (false=0). Allora bitwise A|B|C...>0
E nessuno controllerà le varianti suggerite per la velocità di esecuzione?
Puoi usare lo script da qui
In generale, l'opzione più veloce sarebbe questa:
Tuttavia, un'altra linearesult=false dovrebbe essere meglio combinata con la prima, non influenzerà la velocità.In generale, se A, B, C e D contengono condizioni semplici (con un minimo di aritmetica, senza chiamare tutte le funzioni matematiche e altre cose), allora non si otterrà un gran guadagno di prestazioni da tale ottimizzazione (a meno che questa costruzione non venga eseguita decine di milioni di volte, ovviamente). Ma il sovraccarico di codice può essere significativo.
Ho scritto in uno dei thread che tutto deve essere gestito razionalmente. Per qualche motivo, mi sembra che il tuo codice sia pieno di posti più importanti l'ottimizzazione dei quali darebbe davvero un enorme guadagno di prestazioni. Dovresti iniziare con l'algoritmo di base. La maggior parte dei neofiti hanno un controllo stupido di tutte le condizioni riguardanti TS o ordini aperti ad ogni tick. Ma nella maggior parte dei casi, è sufficiente controllare solo le condizioni limite, per esempio quando l'haul o il low raggiunge un certo valore, o quando appare una nuova barra. Solo dopo si possono eseguire ulteriori controlli.
Beh, oltre ai calcoli ad alta intensità di risorse, dovete pensare a spostare questi calcoli in una DLL. Altrimenti sarebbe spiacevole sedersi e aspettare per 13 minuti nel fottuto MQL4 (anche se potremmo ottenere lo stesso risultato in 2-3 minuti).
In questo modo è anche più veloce.
Ricordo una storia:
"In una riunione del consiglio di amministrazione di un'azienda, c'erano due domande:
1. La decisione di costruire un sincrofasotrone.
2. La decisione di costruire un parcheggio per biciclette per i dipendenti.
Sulla prima questione, la discussione è durata 1 minuto,
il 2, il dibattito è durato più di 2 ore".