Características da linguagem mql5, subtilezas e técnicas - página 49

Novo comentário
 
fxsaber:

Se você pressionar TAB imediatamente após as palavras se, caso contrário, enquanto, para, fazer, há um pouco mais de construção...


Foda-se... Óptimo, depois de 5 anos a conhecer o MQI - eu descobri.

 

Conclusões de uma conversa no SD sobre um problema levantado.

Acontece que a atribuição de um valor a uma variável de string é uma operação MUITO cara.

Tão caro que é desejável evitá-lo tanto quanto possível até que os desenvolvedores melhorem este ponto no compilador, que parece estar muito distante.


Como exemplo, se você fizer uma corrida de tique real por um mês na FIBO, seria cerca de 1 milhão de tiquetaques. Se você conseguir o valor do PositionGetString em cada tick e compará-lo com algo, o desempenho seria aceitável, mas se você primeiro atribuir o resultado da função a uma variável string antes de compará-la, então a duração da execução aumentaria em cerca de um segundo.


Se parece uma coisa pequena, é uma visão equivocada. Quando essa EA é executada em modo de otimização para vários milhares de passes, esse segundo extra se traduz em horas adicionais de tempo de espera. Ou seja, uma atribuição de cordas inofensiva pode causar horas adicionais de espera durante a otimização. Tenha cuidado e leve esta nuance em conta.


No kodobase, existe uma pequena ferramenta que permite detectar tais falhas em diferentes implementações da mesma lógica de negociação. Escreva código rápido.

 
fxsaber:

Conclusões de uma conversa no SD sobre um problema levantado.

Acontece que a atribuição de um valor a uma variável de string é uma operação MUITO cara.

Tão caro que é desejável evitá-lo, se possível, até os desenvolvedores melhorarem este ponto no compilador, o que parece não acontecer em breve.


Como exemplo, se você fizer uma corrida de tique real por um mês na FIBO, seria cerca de 1 milhão de tiquetaques. Se você conseguir o valor do PositionGetString em cada tick e compará-lo com algo, o desempenho seria aceitável, mas se você primeiro atribuir o resultado da função a uma variável string antes de compará-la, então a duração da execução aumentaria em cerca de um segundo.


Se parece uma coisa pequena, é uma visão equivocada. Quando essa EA é executada em modo de otimização para vários milhares de passes, esse segundo extra se traduz em horas adicionais de tempo de espera. Ou seja, uma atribuição de cordas inofensiva pode causar horas adicionais de espera durante a otimização. Tenha cuidado e leve esta nuance em conta.


No kodobase, existe uma pequena ferramenta que permite detectar tais falhas em diferentes implementações da mesma lógica de negociação. Escreva um código rápido.

Obrigado, eu não pensei que fosse possível. Vou tê-lo em conta em futuros desenvolvimentos

 

Um simples enigma para dormir, porquê os resultados amarelos?

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

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

Um simples enigma para dormir, porquê os resultados amarelos?

Como a estrutura está cheia de zeros, não por construtor, então a estrutura de array é inicializada incorretamente, arrayresize não gosta de tais arrays, meu código falhou em tal redimensionamento.
 
Combinador:
Como a estrutura está cheia de zeros, não o construtor, então a estrutura de array é inicializada incorretamente, o arrayresize não gosta de tais arrays, o meu código colapsou em tal tamanho.

É uma coisa boa que todos saibam.

 
Slava:

Refere-se à GetMicrosecondCount. Não há uma forma definitiva de saber se está a atrasar o servidor. Pode ter um efeito indirecto. Portanto, é melhor usar o GetTickCount nativo do sistema

GetMicrosecondCount é usado para medir curtos períodos de execução de código. Para medir um grande número de execuções do OnTick, é melhor usar o GetTickCount.

Tente usar o GetMicrosecondsCount em vez do GetTickCount quando obtiver resultados estáveis. Vais falar-me sobre isso aqui. Talvez esteja a preocupar-me demasiado com isso.

A sua hipótese revelou-se correcta, uma chamada múltipla de GetMicrosecondsCount causa atrasos terríveis no testador. No entanto, o GetTickCount tem o mesmo efeito.
 
fxsaber:

Conclusões de uma conversa no SD sobre um problema levantado.

Acontece que a atribuição de um valor a uma variável de string é uma operação MUITO cara.

Tão caro que é desejável evitá-lo, se possível, até que os desenvolvedores melhorem este ponto no compilador, o que parece não acontecer em breve.


Como exemplo, se você fizer uma corrida de tique real por um mês na FIBO, seria cerca de 1 milhão de tiquetaques. Se você conseguir o valor do PositionGetString em cada tick e compará-lo com algo, o desempenho seria aceitável, mas se você primeiro atribuir o resultado da função a uma variável string antes de compará-la, então a duração da execução aumentaria em cerca de um segundo.


Se parece uma coisa pequena, é uma visão equivocada. Quando essa EA é executada em modo de otimização para vários milhares de passes, esse segundo extra se traduz em horas adicionais de tempo de espera. Ou seja, uma atribuição de cordas inofensiva pode causar horas adicionais de espera durante a otimização. Tenha cuidado e leve esta nuance em conta.


No kodobase, existe uma pequena ferramenta que permite detectar tais falhas em diferentes implementações da mesma lógica de negociação. Escreva um código rápido.

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

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

Acontece que a atribuição de um valor a uma variável de string é uma operação MUITO cara.

...

Se primeiro atribuir o resultado de uma função a uma variável de string antes de comparar, e depois compará-la, então o tempo de execução aumentará cerca de um segundo.

A meu ver, o problema não é tanto com uma tarefa cara, mas com o fato de que o compilador não corta essa tarefa desnecessária do código por alguma razão, embora deva. Ou seja, o código compilado deve ser o mesmo em ambos os casos.
 
Alexey Navoykov:
Como eu entendo, o problema não está tanto na atribuição cara, mas no fato de que o compilador não corta essa atribuição desnecessária do código por alguma razão, mesmo que deveria. Isto é, o código compilado deve ser o mesmo em ambos os casos.

Este é um problema menor. Sim, o otimizador do compilador ainda não sabe como otimizar tais momentos de string. Mas é a atribuição de cordel onde reside o problema da desaceleração.

Escrever código que não pode ser otimizado pelo compilador e ao mesmo tempo fazer atribuições no mesmo. E vais ver o que é um abrandamento.

O exemplo de leitura de um campo de tensão de uma estrutura através de uma função é exactamente a forma como a leitura das propriedades de posição é implementada em MT4/5.

No MT4, o mesmo OrderSymbol() está a travar se for implementado no MT5. Os próprios desenvolvedores tentam passar para as suas funções através de links.

Portanto, se você escrever algo como isto

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

é sempre melhor colocar a condição OrderSymbol() no final da condição geral.


Tenho notado uma aparente desaceleração na superfície aparentemente lisa quando uso o TesterBench.

1...424344454647484950515253545556...247
Novo comentário