É possível evitar muitos "ors" (|||) em condições que causem a mesma ação? - página 6

Novo comentário
 
Meat:

borilunad, qualquer chamada de função acrescenta uma frenagem desnecessária. Portanto, se for necessária velocidade máxima, você deve se livrar de todos os Pedidos(), que realizam operações de uma sílaba. O mesmo se aplica aos laços. A verificação das condições em loop é sempre muito mais lenta do que apenas uma série de aninhados se()

Portanto, mesmo condições mutuamente exclusivas são melhores com a ação do if(A ||| B ||| C || D);

Mas não posso evitar chamadas de função, pois preciso verificar muitos dados nesse ponto, o que está incluído nessas condições.

Continuarei meus experimentos, talvez eu descubra algo. Mas eu não tenho controle sobre a propagação! :)

 
Em geral, a opção mais rápida seria esta:
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();

Entretanto,caso contrário, resultado=linha falsa deve ser melhor combinado com a primeira, não afetará a velocidade.Em geral, se A, B, C e D contiverem condições simples (com aritmética mínima, sem chamadas de todas as funções matemáticas e outras coisas), então você não terá muito ganho de desempenho com tal otimização (a menos que esta construção funcione dezenas de milhões de vezes, é claro). Mas a sobrecarga de código pode ser significativa.

Por alguma razão, parece-me que seu código está cheio de lugares mais importantes, cuja otimização realmente daria um enorme ganho de desempenho. Você deve começar com o algoritmo básico. A maioria dos novatos tem uma verificação idiota de todas as condições referentes a TS ou pedidos em aberto a cada tick. Mas na maioria dos casos, basta verificar apenas as condições de contorno, por exemplo, quando o lanço ou baixa atinge um determinado valor, ou quando aparece uma nova barra. Só depois disso é possível realizar mais verificações.

Bem, além disso, com cálculos intensivos em recursos você precisa pensar em mover estes cálculos para uma DLL. Caso contrário, sentar e esperar 13 minutos na porra do MQL4 (enquanto você pode obter o mesmo resultado por 2-3 minutos) parece ser uma infelicidade :)

 
Meat:
Em geral, a opção mais rápida seria esta:

Entretanto,caso contrário, resultado=linha falsa deve ser melhor combinado com a primeira, não afetará a velocidade.Em geral, se A, B, C e D contiverem condições simples (com aritmética mínima, sem chamadas de todas as funções matemáticas e outras coisas), então você não terá muito ganho de desempenho com tal otimização (a menos que esta construção funcione dezenas de milhões de vezes, é claro). Mas a sobrecarga de código pode ser significativa.

Por alguma razão, parece-me que seu código está cheio de lugares mais importantes, cuja otimização realmente daria um enorme ganho de desempenho. Você deve começar com o algoritmo básico. A maioria dos novatos tem uma verificação idiota de todas as condições referentes a TS ou pedidos em aberto a cada tick. Mas na maioria dos casos, basta verificar apenas as condições de contorno, por exemplo, quando o lanço ou baixa atinge um determinado valor, ou quando aparece uma nova barra. Só depois disso é possível realizar mais verificações.

Bem, além disso, com cálculos intensivos em recursos você precisa pensar em mover estes cálculos para uma DLL. Caso contrário, sentar e esperar 13 minutos na porra do MQL4 (enquanto você pode obter o mesmo resultado por 2-3 minutos) parece ser uma infelicidade :)

A opção mais rápida foi sugerida pela Paco
 
tara:
A opção mais rápida foi sugerida pela Paco

Você realmente acha que é mais rápido somar vários valores cada vez (ou seja, realizar operações aritméticas extras)? Na minha variante a verificação é concluída na primeira partida, enquanto na variante mencionada por você - somente após somar todos os valores e depois verificar a soma.

Além disso, essa variante exige o cálculo antecipado de TODAS as condições. Então de que tipo de velocidade estamos falando aqui? É a opção mais lenta.

 
e trocar - caso não é uma boa idéia?
 

Se você quiser acelerar, você pode tentar operações um pouco mais rápidas.

Isto é, fazer todas as variáveis do tipo int (false=0). Então bitwise A|B|C...>0

 
Avals:

Se você quiser acelerar, você pode tentar operações um pouco mais rápidas.

Isto é, fazer todas as variáveis do tipo int (false=0). Então bitwise A|B|C...>0

E qual é o objetivo de tudo isso? Assim como na soma, todas as condições devem ser pré-calculadas. E por que calculá-las todas, se apenas uma das condições é suficiente.
 

E ninguém vai verificar as variantes sugeridas para a velocidade de execução?

Você pode usar o roteiro a partir daqui

 
Meat:
Em geral, a opção mais rápida seria esta:

Entretanto,caso contrário, resultado=linha falsa deve ser melhor combinado com a primeira, não afetará a velocidade.Em geral, se A, B, C e D contiverem condições simples (com aritmética mínima, sem chamadas de todas as funções matemáticas e outras coisas), então você não terá muito ganho de desempenho com tal otimização (a menos que esta construção funcione dezenas de milhões de vezes, é claro). Mas a sobrecarga de código pode ser significativa.

Por alguma razão, parece-me que seu código está cheio de lugares mais importantes, cuja otimização realmente daria um enorme ganho de desempenho. Você deve começar com o algoritmo básico. A maioria dos novatos tem uma verificação idiota de todas as condições referentes a TS ou pedidos em aberto a cada tick. Mas na maioria dos casos, basta verificar apenas as condições de contorno, por exemplo, quando o lanço ou baixa atinge um determinado valor, ou quando aparece uma nova barra. Só depois disso é possível realizar outras verificações.

Bem, além disso, com cálculos intensivos em recursos você precisa pensar em mover estes cálculos para uma DLL. Caso contrário, seria lamentável sentar e esperar 13 minutos na porra do MQL4 (embora possamos obter o mesmo resultado em 2-3 minutos).

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

É ainda mais rápido desse modo.

Eu me lembro de uma história:

"Em uma reunião da diretoria da empresa, houve duas perguntas:

1. A decisão de construir um synchrophasotron.

2. A decisão de construir um estacionamento de bicicletas para os funcionários.

Na primeira edição, a discussão durou 1 minuto,

no dia 2, o debate durou mais de 2 horas".

 
Quem não gosta da "porra da MQL4" pode muito bem ir correr, correr. Porque não está claro o que ele está fazendo aqui. apesar de todos os méritos e antiguidade da conta.
12345678910
Novo comentário