Caratteristiche del linguaggio mql5, sottigliezze e tecniche - pagina 49

Nuovo commento
 
fxsaber:

Se premi TAB subito dopo le parole if, else, while, for, do, c'è una piccola costruzione extra...


f*cking hell... grande, dopo 5 anni di conoscenza di mql - l'ho scoperto.

 

Conclusioni di una conversazione nella SD su un problema sollevato.

Si scopre che assegnare un valore a una variabile stringa è un'operazione MOLTO costosa.

Così costoso che è auspicabile evitarlo il più possibile finché gli sviluppatori non migliorano questo punto nel compilatore, il che sembra essere molto lontano.


Come esempio, se si esegue una corsa in tick reale per un mese su FIBO, sarebbe circa 1 milione di tick. Se si ottiene il valore di PositionGetString ad ogni tick e lo si confronta con qualcosa, la performance sarebbe accettabile, ma se si assegna prima il risultato della funzione ad una variabile stringa prima di confrontarlo, allora la durata dell'esecuzione aumenterebbe di circa un secondo.


Se sembra una piccola cosa, è una visione sbagliata. Quando un tale EA viene eseguito in modalità di ottimizzazione per diverse migliaia di passaggi, quel secondo in più si traduce in ore aggiuntive di tempo di attesa. Cioè un'innocua assegnazione di stringhe può causare ore di attesa aggiuntive durante l'ottimizzazione. Fate attenzione e tenete conto di questa sfumatura.


In kodobase, c'è un piccolo strumento che permette di rilevare tali fallimenti in diverse implementazioni della stessa logica di trading. Scrivere codice veloce.

 
fxsaber:

Conclusioni di una conversazione nella SD su un problema sollevato.

Si scopre che assegnare un valore a una variabile stringa è un'operazione MOLTO costosa.

Così costoso che è auspicabile evitarlo se possibile finché gli sviluppatori non migliorano questo punto nel compilatore, il che non sembra accadere presto.


Come esempio, se si esegue una corsa in tick reale per un mese su FIBO, sarebbe circa 1 milione di tick. Se si ottiene il valore di PositionGetString ad ogni tick e lo si confronta con qualcosa, la performance sarebbe accettabile, ma se si assegna prima il risultato della funzione ad una variabile stringa prima di confrontarlo, allora la durata dell'esecuzione aumenterebbe di circa un secondo.


Se sembra una piccola cosa, è una visione sbagliata. Quando un tale EA viene eseguito in modalità di ottimizzazione per diverse migliaia di passaggi, quel secondo in più si traduce in ore aggiuntive di tempo di attesa. Cioè un'innocua assegnazione di stringhe può causare ore di attesa aggiuntive durante l'ottimizzazione. Fate attenzione e tenete conto di questa sfumatura.


In kodobase, c'è un piccolo strumento che permette di rilevare tali fallimenti in diverse implementazioni della stessa logica di trading. Scrivere un codice veloce.

Grazie, non pensavo fosse possibile. Ne terrò conto nei futuri sviluppi

 

Un semplice indovinello da letto, perché i risultati gialli?

struct INT
{
  int Array[];
  
  INT()
  {
    Print(__FUNCTION__); // до сюда не дойдет
  }
};

void OnStart()
{
  INT i = {0};
  
  Print(ArrayResize(i.Array, 5)); // -1
}
 
fxsaber:

Un semplice indovinello da letto, perché i risultati gialli?

Perché la struttura è impacchettata con degli zeri, non dal costruttore, quindi la struttura dell'array è inizializzata in modo errato, arrayresize non ama tali array, il mio codice è andato in crash su tale ridimensionamento.
 
Combinatore:
Poiché la struttura è impacchettata con zeri, non il costruttore, quindi la struttura dell'array è inizializzata in modo errato, arrayresize non ama tali array, il mio codice è andato in crash su tale ridimensionamento a tutti.

È un bene che tutti lo sappiano.

 
Slava:

Si riferisce a GetMicrosecondCount. Non c'è un modo preciso per dire se sta rallentando il server. Può avere un effetto indiretto. Pertanto, è meglio usare il nativo GetTickCount del sistema

GetMicrosecondCount è usato per misurare brevi periodi di esecuzione del codice. Per misurare un gran numero di esecuzioni OnTick, è meglio usare GetTickCount.

Prova a usare GetMicrosecondsCount invece di GetTickCount quando ottieni risultati stabili. Me ne parlerai qui. Forse mi sto preoccupando troppo.

La tua ipotesi si è rivelata corretta, una chiamata multipla di GetMicrosecondsCount causa terribili ritardi nel tester. Tuttavia, GetTickCount ha lo stesso effetto.
 
fxsaber:

Conclusioni di una conversazione nella SD su un problema sollevato.

Si scopre che assegnare un valore a una variabile stringa è un'operazione MOLTO costosa.

Così costoso che è auspicabile evitarlo se possibile finché gli sviluppatori non migliorano questo punto nel compilatore, il che non sembra accadere presto.


Come esempio, se si esegue una corsa in tick reale per un mese su FIBO, sarebbe circa 1 milione di tick. Se si ottiene il valore di PositionGetString ad ogni tick e lo si confronta con qualcosa, la performance sarebbe accettabile, ma se si assegna prima il risultato della funzione ad una variabile stringa prima di confrontarlo, allora la durata dell'esecuzione aumenterebbe di circa un secondo.


Se sembra una piccola cosa, è una visione sbagliata. Quando un tale EA viene eseguito in modalità di ottimizzazione per diverse migliaia di passaggi, quel secondo in più si traduce in ore aggiuntive di tempo di attesa. Cioè un'innocua assegnazione di stringhe può causare ore di attesa aggiuntive durante l'ottimizzazione. Fate attenzione e tenete conto di questa sfumatura.


In kodobase, c'è un piccolo strumento che permette di rilevare tali fallimenti in diverse implementazioni della stessa logica di trading. Scrivere un codice veloce.

struct STRUCT
{
  string Str;
  
  string Get() const { return(this.Str); }
};

void OnStart()
{
  STRUCT Struct;
  
  Print(Struct.Str);
  Print(Struct.Get()); // Выполняется гораздо дольше, чем предыдущая строка
}
 
fxsaber:

Si scopre che assegnare un valore a una variabile stringa è un'operazione MOLTO costosa.

...

Se si assegna prima il risultato di una funzione a una variabile stringa prima del confronto, e poi lo si confronta, il tempo di esecuzione aumenterà di circa un secondo.

Per come la vedo io, il problema non è tanto con l'assegnazione costosa, ma con il fatto che il compilatore non taglia questa assegnazione non necessaria dal codice per qualche motivo, anche se dovrebbe. Cioè, il codice compilato dovrebbe essere lo stesso in entrambi i casi.
 
Alexey Navoykov:
Per come la vedo io, il problema non è tanto nell'assegnazione costosa, ma nel fatto che il compilatore non taglia questa assegnazione non necessaria dal codice per qualche motivo, anche se dovrebbe. Cioè il codice compilato dovrebbe essere lo stesso in entrambi i casi.

Questo è un problema minore. Sì, l'ottimizzatore del compilatore non sa ancora come ottimizzare tali momenti di stringa. Ma è l'assegnazione delle stringhe dove si trova il problema del rallentamento.

Scrivere codice che non può essere ottimizzato dal compilatore e allo stesso tempo fare assegnazioni in esso. E vedrete cos'è un rallentamento.

L'esempio della lettura di un campo stringa di una struttura attraverso una funzione è esattamente il modo in cui la lettura delle proprietà di posizione è implementata in MT4/5.

In MT4, lo stesso OrderSymbol() è frenato se è implementato in MT5. Gli stessi sviluppatori cercano di passare alle loro funzioni delle stringhe tramite link.

Pertanto, se si scrive qualcosa come questo

if ((OrderSymbol() == Symb) && (OrderMagicNumber == Magic))

è sempre meglio mettere la condizione OrderSymbol() alla fine della condizione generale.


Ho notato un apparente rallentamento su superfici apparentemente lisce quando uso TesterBench.

1...424344454647484950515253545556...247
Nuovo commento
Motivazione: