Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Mesmo assim, o código superior às vezes vence, mas muito raramente, ou seja, o link é livre.
) bem, não é assim que funciona)
É assim que funciona em C++
Em mql acho que é o mesmo, mas com invólucros adicionais da MQ
Fórum sobre comércio, sistemas automatizados de comércio e testes estratégicos
FAQ de Iniciantes MQL5 MT5 MetaTrader 5
Roman, 2019.12.11 14:02
Você não tem que pensar bem, por que eu deveria... O compilador fará tudo sozinho. ))
C# não é C
Dê uma olhada no vídeo sobre __em linha.
Explica ali como funcionam as funções em memória daqueles que não fazem nenhuma diferença.
É assim que funciona em C++
Em mql penso o mesmo, mas com invólucros adicionais da MQ
Bem, agora releia este tópico e muitas declarações e exemplos de testes - que há alguma diferença. E nós o encontramos))))
Bem, agora releia este tópico e um monte de declarações e exemplos de testes - que há uma diferença. E eles fizeram))))
Não )) Não tenho desejo de relê-lo.
É óbvio para mim que existe uma diferença.
Não )) Não tenho vontade de relê-lo.
É óbvio para mim que existe uma diferença.
)))) outro IMHO.
A via superior é mais rápida em quase 15% isso é muito significativo, bem, se tudo é tão óbvio me explique isso)
)))) outra IMHO
O caminho superior é mais rápido em quase 20%, bem, já que tudo é tão óbvio me explica isso)
Os laços que estão sendo comparados não são os mesmos em termos de código no corpo.
O primeiro laço tem um código no corpo, o segundo laço no corpo tem outro código.
Instruções de código naturalmente diferentes, tempo de execução naturalmente diferente.
Faça o mesmo código no corpo do loop e mude somente a condição do loop ArraySize e a variável de tamanho.
Estamos testando esta parte, não o corpo.
Os loops que estão sendo comparados não são o mesmo código no corpo.
O primeiro laço tem um código em seu corpo e o segundo laço tem outro código.
Naturalmente, instruções de código e tempo de execução diferentes são diferentes.
Faça o mesmo código no corpo do loop e mude somente a condição do loop ArraySize e a variável de tamanho.
Estamos testando esta parte, não o corpo.
Seu teste é mais incorreto porque depende do caso de lançamento, execute-o novamente. Aqui, em ambos os casos, há um incremento e uma divisão. Bem, além disso, há um par de dezenas extras ~ bilhões de chamadas ArraySize no topo.
A propósito, é no corpo que devemos escrever o que estamos testando. Porque é o corpo que se repete. Estamos tentando embrulhá-lo em loop.... para obter um resultado ou seja, era originalmente necessáriochamar o ArraySize do corpo
Seu teste é mais incorreto, pois depende do caso de lançamento, execute-o novamente. Aqui ambos os casos têm incremento e uma divisão. Bem, além disso, há um par de dezenas~ bilhões de chamadas ArraySize em cima dele.
A propósito, é no corpo que devemos escrever o que estamos testando. Porque é o corpo que se repete. Estamos tentando embrulhá-lo em loop.... para obter um resultado ou seja, foi inicialmente necessáriochamar o ArraySize do corpo
A cada iteração, a condição do laço já contém uma verificação da condição i<ArraySize() ou i<size
, ou seja, a cada iteração, uma função ou uma variável é chamada.
Por que devemos colocar o objeto a ser testado no corpo?
A própria lógica nos leva a decidir qual deles será mais rápido de se lidar. A uma função ou a uma variável.
Não me interessa o que o compilador lhe chama. Não estou confiando no compilador, estou apenas usando meu bom senso para descobrir o que é mais rápido de se lidar do ponto de vista de referência.
A cada iteração, na condição do loop, a condição i<ArraySize() ou i<size
é verificada de qualquer forma, o que significa que a cada iteração é chamada uma função ou uma variável.
Por que devemos colocar o objeto a ser testado no corpo?
Porque nós somos os sortudos que têm esta função e a função pode ser qualquer outra. E é colocado exatamente no corpo. Eu só o dupliquei na tentativa de melhorar seu efeito e abordar diferentes matrizes.
Mas é errado acrescentar tarefas mais complexas, cujo erro de cálculo pode ofuscar o efeito em estudo. A propósito, também é possível que a montagem não seja constante em μl. Ou seja, quando a recompilação pode obter dados ligeiramente diferentes (embora isto não seja exato, mas é meio que usado como proteção contra hacking), então tudo pode ser testado em seu código para você também. Veja se os resultados mudam.
Mcl simplesmente tenta substituir o código como indicado no vídeo. Bem, lá é um pouco diferente. Mas em termos gerais.
E aquelas instruções de funções que não sabem que valor terão - é assim que js e php e outros idiomas semelhantes funcionam, mesmo µl funciona desta forma, mas apenas em modo de depuração
A cada iteração, na condição de loop, a condição i<ArraySize() ou i<size
é verificada de qualquer forma, o que significa que a cada iteração, uma função ou uma variável é acessada.
Por que devemos colocar o objeto a ser testado no corpo?
A própria lógica nos leva a decidir qual deles será mais rápido de se lidar. A uma função ou a uma variável.
Não me interessa o que o compilador lhe chama. Eu não confio no compilador, confio no bom senso e descubro o que é mais rápido de se lidar do ponto de vista da referência.
Nem sempre funciona.
Fórum sobre comércio, sistemas automatizados de comércio e testes de estratégia comercial
Pergunta para #define experts
Romano, 2020.11.02 19:44
Mudei meu posto.
É o contrário, ou seja, o ArraySize é mais rápido agora do que o cnt.
Era o inverso antes. Talvez o cnt de incremento - afeta, o corpo do laço é diferente e provavelmente algo mais deve ser inventado para a carga.