Erros, bugs, perguntas - página 2749

Novo comentário
 
Roman:

Na página anterior fxsaber deu medidas.
Expliquei porque é que é este o caso.
Alocar sempre memória, de forma estática ou dinâmica.

Que tipo de medidas? Se se refere a uma mesa grande, então apenas parte esquerda é visível no ecrã, o resto é cortado, por isso não sei o que está lá.

Mas, a julgar pelo código, se esta macro for comparada

GetCurrentTick2(Tick, !i)

Tenho apenas uma chamada de função por 100 iterações. E a primeira macro tem uma chamada em cada iteração. Por isso não faz sentido.

 
Alexey Navoykov:

Se se refere à mesa grande, apenas a parte esquerda é visível no ecrã, o resto é cortado, por isso não sei o que está lá.

Mas, a julgar pelo código, se esta macro for comparada

E na primeira macro, há apenas uma chamada de função por 100 iterações. Portanto, isto é um disparate.

O compilador não é omnipotente, por vezes é preciso participar e ajudá-lo com o código certo ))

 
Sergey Dzyublik:
Bug in ME debugger(build 2370) - StepInto (F11) e definir manualmente os pontos de interrupção não funciona.
O problema é que se a acção StepOver (F10) for aplicada a uma chamada de função pelo menos uma vez, não há forma de depurar esta função mais tarde.

Passos de repetição:
1) Executar código em modo de depuração;
2) Depois de um ponto de quebra ser accionado, executar StepOver (F10) duas vezes;

Tudo - agora não há maneira de "entrar" na funçãoIncremento, todos os pontos de quebra definidos manualmente não são accionados, e em vez de StepInto operation (F11), StepOver (F10) é realmente executado.


Obrigado pelo correio.

Corrigido por

 
Roman:

O compilador não é omnipotente, por vezes é preciso envolver-se ))

O que quer dizer? Garantiu-me que a sua construção é mais rápida, mas não é. É apenas 100 vezes menos provável que seja chamada nesse código.
 
Alexey Navoykov:

Na primeira macro, há apenas uma chamada de função por 100 iterações, o que é um disparate.

O teste, se não for para escolher a precisão, que não precisamos aqui, é mais ou menos normal.
Em comparação com: chamar 100 vezes SymbolInfoTick VS chamar 1 vez SymbolInfoTick e devolver 99 vezes a cache "manual".
Mostra como é pouco rentável utilizar a função SymbolInfoTick padrão para o símbolo actual quando a função será chamada mais de uma vez numa única passagem.
Como solução possível para o problema, os criadores sugerem a introdução de uma variável pré-definida:

const MqlTick _Tick; // Текущий _Symbol-тик.



É queo fxsaber espalhou tudo pelos postes sem explicar absolutamente nada, é uma coisa infernal a fazer.

 
Alexey Navoykov:

Na primeira macro, há apenas uma chamada de função por 100 iterações, o que é um disparate.

O seu exemplo é um uso específico de dados de licitação/venda em diferentes partes do programa MQL, quanto mais frequentemente acede a SymbolInfoTick(), mais baixo é o desempenho do teste

Encontrei alguns problemas de desempenho com o TimeCurrent(), experimentei-o de formas diferentes, depois descartei-o,

Raramente uso visibilidade variável global, mas para que tudo "voe" no testador, escrevo-o desta forma:

MqlTick Tick = {0};
#define  Ask Tick.ask
#define  Bid Tick.bid
#define  TimeCurrent_ Tick.time
//+------------------------------------------------------------------+
void OnTick()
{
   SymbolInfoTick(_Symbol,Tick);
  ....
}
 
Alexey Navoykov:
O que quer dizer? Garantiu-me que o seu desenho é mais rápido, e não é mais rápido, é apenas 100 vezes menos provável que seja chamado nesse código.

Este não é o meu desenho, e como entendi desse exemplo, as macros foram chamadas uma a uma para o teste.
E o relatório do passe é mostrado em conjunto, apesar de estar cortado, é possível ver o tempo de execução.

 
Sergey Dzyublik:

O teste, se não se preocupar com a precisão, que não é necessária, é mais ou menos normal.
Comparação: chamando 100 vezes SymbolInfoTick VS chamando 1 vez SymbolInfoTick e devolvendo 99 vezes a cache "manual".

Sim, eu compreendo a cache. É que aqui o Roman estava a esfregar algo sobre a alocação de memória... Parece que tinhas razão sobre o troll )

 
Alexey Navoykov:

Eu sei sobre a cache. É que aqui o Roman estava a esfregar algo sobre a alocação de memória... Parece que tinhas razão sobre o troll )

Onde pensa que a cache é atribuída? Seus manequins.

 
Sergey Dzyublik:

O teste, se não se preocupar com a precisão, que não é necessária, é mais ou menos normal.
Comparação: chamando 100 vezes SymbolInfoTick VS chamando 1 vez SymbolInfoTick e devolvendo 99 vezes a cache "manual".
Mostra como é pouco rentável utilizar a função SymbolInfoTick padrão para o símbolo actual quando a função será chamada mais de uma vez numa única passagem.
Como solução possível para o problema, os criadores são encorajados a introduzir uma variável pré-definida:

O meu ponto de vista é 100%.

A razão é queo fxsaber tinha espalhado tudo nos seus postos sem o explicar e é difícil de compreender.

Lamento, mas não o formulo bem.

1...274227432744274527462747274827492750275127522753275427552756...3184
Novo comentário