Bibliotecas: TesterBenchmark - página 3

Novo comentário
 
Andrey Khatimlianskii:

Vasily, você está falando seriamente sobre a comensurabilidade da velocidade de execução do OrderSend no testador e na realidade?

Online é a mais lenta, porque envia informações para o servidor e espera por uma resposta, enquanto no testador (se você não incluir o atraso, mas isso estava fora de questão), o envio e a espera acontecem instantaneamente.

A tarefa dessa biblioteca é apenas medir a velocidade do testador (em termos de funções de negociação).

Sim, eu não pensei nisso. Meu erro. Especificamente, o OrderSend funciona muito mais rápido no testador. Mas continuo afirmando que a maior parte do tempo de teste é consumida pelas funções do sistema. E no MT5 ela é consumida muito bem, porque lá, ao contrário do MT4, há uma simulação completa do ambiente de negociação. É por isso que, mesmo que o pipelining seja acelerado em 16%, será 16% de 5% do tempo total gasto por esse mesmo pipelining. Ou seja, qualquer ideia de otimização de código no MT5 é muito nobre, mas inútil, porque, na melhor das hipóteses, melhoraremos o índice em 5%.

 
Vasiliy Sokolov:

Sim, eu não estava pensando. Meu erro. O OrderSend funciona muito mais rápido no testador. Mas continuo afirmando que a maior parte do tempo de teste é consumida pelas funções do sistema. E no MT5 ela é consumida muito bem, porque lá, ao contrário do MT4, há uma simulação completa do ambiente de negociação. É por isso que, mesmo que o pipelining seja acelerado em 16%, será 16% de 5% do tempo total gasto por esse mesmo pipelining. Ou seja, qualquer ideia de otimização de código no MT5 é muito nobre, mas inútil, porque, na melhor das hipóteses, melhoraremos o índice em 5%.

Não concordo com a última afirmação.

Graças à pesquisa de fxsaber, o MT5 já acelerou o trabalho com o histórico de negociações em ordens de magnitude.

 
Andrey Khatimlianskii:

Discordo da última afirmação.

Graças à pesquisa do fxsaber, o MT5 já é muito mais rápido no trabalho com o histórico de negociações.

Não estou discutindo. Fxsaber contribui muito para o desenvolvimento da linguagem e da comunidade em geral. Ele faz as coisas certas. Há muitos erros no MT5 e é ótimo que alguém os encontre. Mas não se deve confundir erros grosseiros no trabalho com o MT5, como resultado dos quais a velocidade de trabalho diminui em ordens de magnitude, com a captura de pulgas no código SB. Em algum lugar, certamente é possível e até mesmo necessário acelerar a biblioteca. Mas se não houver erros graves nela, não haverá aceleração em ordens de magnitude.

 
Vasiliy Sokolov:

Não estou discutindo. O Fxsaber contribui muito para o idioma e para a comunidade como um todo. Ele faz as coisas certas. Há muitos erros no MT5 e é ótimo que alguém os encontre. Mas não se deve confundir erros grosseiros no trabalho com o MT5, como resultado dos quais a velocidade de trabalho diminui em ordens de magnitude, com a captura de pulgas no código SB. Em algum lugar, certamente é possível e até mesmo necessário acelerar a biblioteca. Mas se não houver erros graves nela, não haverá aceleração em ordens de magnitude.

Eu nem sequer pensei no SB.

Acho que ele só veio à tona para comparação.

 
Andrey Khatimlianskii:

Não concordo com a última afirmação.

Graças à pesquisa do fxsaber, o MT5 já acelerou o trabalho com o histórico de negociações em ordens de magnitude.

A propósito, a propósito, ohistórico de negociações deu errado em 2013. Lembro-me de ter notado que o código a seguir não funciona linearmente:

int total = HistoryDealsTotal();
for(int i = 0; i < total; i++)
{
   ulong ticket = HistoryDealTicket(i);
   HistoryDealSelect(ticket);
}

Ou seja, quanto maior o valor de i, mais lento o HistoryDealSelect funciona. A desaceleração era exponencial. Então, tive que desenhar um gráfico dessa lentidão no Excel e me comunicar com o Service Desk. Portanto, sim, houve e haverá bugs.

 

Agora, alterei um pouco o código, mudando OrderSend para OrderSendAsynch. Os resultados são esperadamente diferentes:

85% do tempo é consumido pelo HistorySelect. Ou seja, estamos de volta às chamadas de sistema, mas um pouco diferente.

 
A biblioteca foi criada para essa finalidade
Ao escrever diferentes versões de código, pode ser necessário medir sua influência no desempenho geral do Expert Advisor no testador. Isso permite que você não apenas entenda o quão otimizado é o código escrito em comparação com outro, mas também fornece pré-requisitos para uma futura otimização rápida do Expert Advisor. Essa abordagem nos permite identificar o "gargalo" no desempenho do EA.

E essa abordagem funcionou não apenas com o MT4Orders.mqh, mas também com o Trade.mqh - ele ficou visivelmente mais rápido após o SD. Além disso, os resultados do uso da biblioteca nos permitiram acelerar visivelmente algumas outras coisas(em particular).

Soluções racionais sólidas , etc.

Fato - o tempo para a otimização depende muito de como o código é escrito. A biblioteca queria convenientemente chamar a atenção não só minha, mas também de outras pessoas para isso.

Como exemplo (que o autor me perdoe), há muitos EAs no kodobase que, em termos de desempenho, não brilham no Otimizador, pelo menos por causa da biblioteca de negociação usada. De fato, esse é até mesmo um certo flagelo do kodobase (e, tenho certeza, do Market), quando um consultor OOP inteligente e forte nega todos os recursos de velocidade do testador MT5.

Quase nada parece ter sido escrito para o testador. E esse é um grande componente do trabalho com o TS.

 
fxsaber:

... quando um consultor OOP inteligente e forte anula todos os recursos de velocidade do testador MT5.

Dê outra olhada no perfil do seu exemplo. Tudo é prejudicado pela lentidão infernal de HistorySelect(0, TimeCurrent). Na OOP, você pode ignorar a chamada de HistorySelect, o que reduz significativamente o tempo de execução do programa em comparação com a chamada de funções MQL5 puras. A afirmação de que a OOP anula todos os recursos de velocidade do MT5 está incorreta. Em alguns casos, graças a ela, você pode aumentar a velocidade, pelo contrário, como no caso do HistorySelect.

 
Vasiliy Sokolov:

Dê outra olhada no perfil do seu exemplo. Tudo é prejudicado pela lentidão infernal de HistorySelect(0, TimeCurrent). Na OOP, é possível ignorar a chamada de HistorySelect, o que reduz significativamente o tempo de execução do programa em comparação com a chamada de funções MQL5 puras. A afirmação de que a OOP anula todos os recursos de velocidade do MT5 está incorreta. Em alguns casos, graças a ela, você pode aumentar a velocidade, pelo contrário, como no caso do HistorySelect.

Por algum motivo, você não vê que o HistorySelect é chamado somente quando não há posições abertas. Além disso, uma nova posição é aberta imediatamente após isso. Ou seja, o histórico é chamado muito raramente. Há um fato (pelo menos verifique o tempo nos logs) de que o tempo no Tester difere dependendo da implementação.


Eu escrevo tudo por meio de OOP e nunca nem sequer mencionei sua possível lentidão. A grande maioria dos autores especialmente interessados em OOP cria, às vezes, designs MUITO convenientes e bonitos. Entretanto, eles não prestam atenção ao desempenho de suas soluções. E isso é muito importante para um testador. Todo mundo quer otimizar seu EA para ser muitas horas mais rápido (ou mais barato na nuvem). Muitas vezes, acontece que algum módulo de OOP escrito há muito tempo e automaticamente conectável contém um gargalo. Mas ninguém percebe isso, é claro.


Você pode escrever seu próprio Expert Advisor que mostre o desempenho da API de negociação usada. Por exemplo, remova o acesso ao histórico e o cálculo de lote do original.

 
fxsaber:

Você pode escrever seu próprio Expert Advisor que mostre o desempenho da API de negociação usada. Por exemplo, do original, jogue fora o acesso ao histórico e o cálculo do lote.

No CStrategy, as operações de negociação são realizadas diretamente pela CTrade. Ou seja, o CStrategy não tem nenhuma lógica de negociação própria. No Expert Advisor de teste, não vi nenhuma outra lógica de negociação além da abertura/fechamento de uma posição em N segundos. O CStrategy também não armazena posições históricas, portanto, infelizmente, esse exemplo não pode ser realizado no CStrategy.

fxsaber:

A grande maioria dos autores especialmente apaixonados por OOP cria, às vezes, construções MUITO convenientes e bonitas.

Infelizmente, a grande maioria dos autores que são apaixonados por OOP não existe em princípio. Pode haver apenas 5 a 10 autores de OOP em todo o recurso, incluindo os autores de SB da MetaQuotes. Somos poucos e estamos em busca de selos:)

fxsaber:

Escrevo tudo em OOP e nunca sequer mencionei sua possível lentidão. A maioria esmagadora dos autores que se interessam especialmente por OOP cria, às vezes, designs MUITO convenientes e bonitos. Entretanto, eles não prestam atenção ao desempenho de suas soluções. E isso é muito importante para um testador. Todo mundo quer otimizar seu EA para ser muitas horas mais rápido (ou mais barato na nuvem). Muitas vezes, acontece que algum módulo OOP escrito há muito tempo e automaticamente conectável contém um gargalo. Mas é claro que ninguém percebe isso.

O fato de o código OOP ser executado mais lentamente do que o código procedural não me diz nada. Vamos direto ao ponto: quais métodos do CTrade são o gargalo? Por quê? O que o perfil desses métodos lhe diz? Como identificar seções de código lento no testador?

1234
Novo comentário