Sobre o profiler do código MT5 - página 3
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
Como um acompanhamento:
Qual das linhas (1, 2 ou 3) ainda é de recursos intensivos?
Eu não consigo entender como o iTime "pesado", que leva 55% do tempo de todo o programa, mostra apenas 0,81% de Auto CPU?
E vice versa - por que o suporte de abertura (1) e a condição mais simples (2, verdade muito raramente) mostram 33,84% de Auto CPU?
Por que a Auto CPU e a CPU Total não são compatíveis?
A função é realmente pesada, mas todo o seu peso está localizado mais abaixo no código. E o profiler sugere a procura de um substituto para o iTime e duas variáveis booleanas?!
Obviamente, eu não entendo algo.
Obviamente me está faltando algo.
Escorregando talvez?
Escorregando talvez?
Não parece ser assim, os números do relatório são os mesmos.
Ilyas, ajude-me a descobrir isso também.
1. Por que uma chamada de função vazia pode levar 34,5% de Auto CPU? Ao mesmo tempo, a chamada da função que a segue, cujos internos ocupam 38,16% do total da CPU, não aparece no relatório de forma alguma?
Código de função:
2. Este exemplo mostra o segundo problema: a linha com TimeCurrent() leva um tempo exageradamente longo não apenas dentro da função, mas no programa em geral:
Antes de comentar o corpo da CheckTimeSeries(), a carga principal estava em sua linha TimeCurrent().
É realmente uma função tão pesada? Com o que substituí-lo? Ou como torná-lo econômico (caching dentro de um loop da execução do programa)?
Onde quer que eu possa, eu salvo os cálculos, diluindo-os (uma vez por barra, uma vez a cada X segundos, uma vez a cada Y ms, etc.). Mas acontece que a verificação em si, se deve ou não fazer os cálculos, é bastante intensiva em recursos.
Obrigado pela ajuda.
1) Sem código é difícil dizer porque estas estatísticas são tão ruins, talvez devido à otimização
2) Por que não tentar obter o tempo na função Temporizador, antes do loop e passá-lo como parâmetro, de que adianta chamar esta função pelo menos 2*N vezes no loop ?
Como um acompanhamento:
Qual das linhas (1, 2 ou 3) ainda é de recursos intensivos?
Eu não consigo entender como o iTime "pesado", que leva 55% do tempo de todo o programa, mostra apenas 0,81% de Auto CPU?
E vice versa - por que o suporte de abertura (1) e a condição mais simples (2, verdade muito raramente) mostra 33,84% de Auto CPU?
Por que a Auto CPU e a CPU Total não são compatíveis?
A função é realmente pesada, mas todo o seu peso está localizado mais abaixo no código. E o profiler sugere a procura de um substituto para o iTime e duas variáveis booleanas?!
Obviamente, eu não entendo algo.
1) Suponho que a função tenha sido simplificada
2) Os contadores são realmente não relacionados, SelfCPU é a carga no código da função, sem levar em conta as funções chamadas, no código dado, é um abridor IF (ramificação)
3) O contador TotalCPU mostra a carga do ramo de execução, para todas as chamadas neste ramo do programa
Não deveria ser sempre 100%? Ou ainda um pouco menos, considerando também @global_initializações e @global_deinicializações.
Aqui está mais de 102% ...(Construir 3003 sobre dados históricos).
1) Suponho que a função tenha sido simplificada
2) Os contadores não estão realmente relacionados, o SelfCPU é a carga no código da função, sem levar em conta as funções chamadas, no código acima, é um abridor IF (ramificação)
3) O contador TotalCPU mostra a carga de um ramo de execução, para todas as chamadas neste ramo do programa.
Qual é a sua utilidade? Obviamente, a declaração IF por si só tem uma baixa carga de CPU. Não deveria incluir chamadas de função?
Em qualquer caso. Como entender (a partir do exemplo de Andrew):
if(!simulated) taking 3.86% ?!?
E quanto a isto ????
onde parecemos estar na mesma função do Tick ()!
Eu realmente quero usar o Profiler e entendê-lo, mas nada disso faz sentido. Desculpe.
O que fazer ? Como podemos ajudar ?
1) Sem código é difícil dizer por que as estatísticas são tão ruins, talvez seja por causa da otimização
2) Por que não tentar obter o tempo na função Timer antes do loop e passá-lo como parâmetro, qual é o objetivo de chamar esta função pelo menos 2*N vezes no loop ?
Obrigado pelas respostas!
1) Eu dificilmente posso reproduzi-lo em um código simples, sim. E eu não estou pronto para entregar o projeto inteiro.
2) Neste caso em particular, concordo.
Mas há muitas outras classes que usam o mesmo controle ou um controle semelhante e não podem passar sem o TimeCurrent ou GetTickCount.
Como otimizar sua chamada para não solicitar o mesmo valor várias vezes?
E o TimeCurrent é realmente tão pesado, que pode ser notado no fundo de cálculos realmente pesados (mesmo se realizados a cada 1 ou 5 minutos)?
Ou eu me enganei novamente e 38,16% do Total de CPU / 26,07% do Auto CPU foi ocupado verificando se ele mesmo (sem considerar a chamada de funçãoTimeCurrent)? Mas por que isto é assim?
1) Vou assumir que a função estava em linha
2) Os contadores não estão realmente relacionados, SelfCPU é a carga sobre o código da função, não levando em conta as funções chamadas, no código acima, é o abre IF (ramificação)
3) O contador TotalCPU mostra a carga de um ramo de execução, por todas as chamadas neste ramo do programa
1) Não ajuda a entender por que um parêntese de abertura tão voraz. Como interpretar isto?
2) Sobre o SelfCPU agora está claro, obrigado. É uma carga de código de função sem considerar as funções que estão sendo chamadas.
Isto também explica o baixo SelfCPU do fio com o iTime - foi muito raramente alcançado, só raramente foi chamado.
Mas por que a TotalCPU é tão alta? Ou mostra a carga de todas as funções do iTime (e outras funções do CopyXXX?) em todo o programa?
Obrigado por suas respostas!
1) Acho que não consigo reproduzi-lo em código simples, sim. E eu não estou pronto para entregar o projeto inteiro.
2) Neste caso em particular, concordo.
Mas há muitas outras classes que usam o mesmo controle ou um controle semelhante e não podem passar sem o TimeCurrent ou GetTickCount.
Como otimizar sua chamada para não solicitar o mesmo valor várias vezes?
E o TimeCurrent é realmente tão pesado, que pode ser notado no fundo de cálculos realmente pesados (mesmo se realizados a cada 1 ou 5 minutos)?
Ou talvez eu tenha me enganado novamente e 38,16% do Total de CPU / 26,07% do Auto CPU foi ocupado pela própria verificação (sem a chamada de funçãoTimeCurrent)? Mas então por que é assim?
1) Não ajuda a entender por que um parêntese de abertura tão voraz. Como interpretar isto?
2) Sobre o SelfCPU agora está claro, obrigado. É uma carga de código de função sem considerar as funções que estão sendo chamadas.
Isto também explica o baixo SelfCPU do fio com o iTime - foi muito raramente alcançado, só raramente foi chamado.
Mas por que um TotalCPU tão grande? Ou mostra a carga de todas as funções do iTime (e outras funções do CopyXXX?) em todo o programa?
Pegue qualquer código da entrega padrão, revise-o e faça perguntas com base nele, por favor. Isto permitirá uma avaliação reprodutível da situação e fornecerá respostas precisas.
Caso contrário, não adianta responder a pequenos trechos de seu código para relatórios de perfiladores. Há uma enorme quantidade de trabalho de otimização nos bastidores, o que transforma todo o seu código em uma representação completamente diferente e embutida.
Para informação: Deus proíbe que 1 em cada 100 programadores de C++ possa usar o perfilador e compreender seus relatórios. A razão é o otimizador de código nativo.
Em qualquer caso. Como entender (a partir do exemplo de Andrew):
if(!simulated) taking 3.86% ?!?
Sim, sem considerar as chamadas de funções externas, a SelfCPU não é muito informativa. Somente no nível mais baixo, onde são utilizadas funções MQL nativas, você verá a carga real.
Mas neste caso não ficará claro de quais lugares essas funções são chamadas com mais freqüência (e consomem mais), e de quais há chamadas únicas! Bem, para que serve saber que as funções CopyXXX e OrderXXX são as que mais consomem tempo? Preciso saber de quais pedaços do meu programa eles são chamados com demasiada freqüência/ineficiência.
Acho que é para isso que serve o modo
, combinado com o TotalCPU. Estarei investigando. Mas até agora vejo até linhas completamente comentadas (!).