È possibile evitare molti "o" (||) nelle condizioni che causano la stessa azione? - pagina 6

Nuovo commento
 
Meat:

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! :)

 
In generale, l'opzione più veloce sarebbe questa:
bool result;
if (A) result=true;
else
if (B) result=true;
else
if (C) result=true;
else
if (D) result=true;
else result=false;

if (result) Action();

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 :)

 
Meat:
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
 
tara:
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.

 
e switch - caso non è una buona idea?
 

Se volete accelerare, potete provare le operazioni bitwise.

Cioè rendere tutte le variabili di tipo int (false=0). Allora bitwise A|B|C...>0

 
Avals:

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 che senso ha tutto questo? Come per la somma, tutte le condizioni devono essere precalcolate. E perché calcolarle tutte, se basta una sola delle condizioni.
 

E nessuno controllerà le varianti suggerite per la velocità di esecuzione?

Puoi usare lo script da qui

 
Meat:
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).

if (A) Action();
 else
  if (B) Action();
   else
    if (C) Action();
     else
      if (D) Action();

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".

 
Chi non ama il "fottuto MQL4" potrebbe anche andare a correre, correre. Perché non è chiaro cosa stia facendo qui, nonostante tutti i meriti e l'antichità del racconto.
12345678910
Nuovo commento
Motivazione: