Erros, bugs, perguntas - página 2776
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
Isto não é um erro, é o custo de um comando de sincronização com um gráfico
Porque precisa de um comando a um gráfico para retirar características do mesmo? Não existe apenas uma tabela de características de todos os gráficos em memória, da qual se pode simplesmente obter dados em nanossegundos em vez de milissegundos (nem sequer microssegundos!)
É evidente que as funções ChartSetInteger, ChartSetDouble, ChartSetString são assíncronas.
Mas porque é que as funções ChartGetInteger, ChartGetDouble, ChartGetString se comportam como assíncronas em termos de velocidade de execução quando são síncronas?
Se tal tabela não existe na memória e estas funções precisam de abrandar o gráfico de cada vez para que possa gerar o parâmetro solicitado, então não compreendo nada.
Não é caro ter uma tal mesa e mantê-la actualizada. Realisticamente alguns quilobytes na memória e uma pequena fracção de um microssegundo para actualizar a tabela quando as características do gráfico mudam.
Ilyas, por favor diz-me, o que me está a faltar?
Mas porquê então as funções ChartGetInteger, ChartGetDouble, ChartGetString comportam-se de forma assíncrona em termos de velocidade de execução, quando são síncronas?
Tem algum tipo de compreensão incorrecta dos termos assíncrono e síncrono.
Quando dizem que uma função é assíncrona, significa que será executada não no fio actual da execução mas em algum outro fio - paralelo.
A função é assíncrona - significa que a função não espera pela execução do comando enfileirado com sucesso no gráfico especificado, mas devolve imediatamente o controlo.
A propriedade só mudará depois de o comando ter sido processado na fila do gráfico. AfunçãoChartRedrawdeve ser chamada para executar imediatamente os comandos na fila do gráfico.
A chamada assíncrona como a função ChartSetInteger a partir do fio principal é rápida à medida que a execução real se realiza noutro fio.
Por outro lado, chamar a função síncrona ChartGetInteger exigirá a sincronização dos fios e isto pode exigir tempo adicional.
Os atrasos são especialmente notáveis quando o fio paralelo está constantemente a actualizar os dados da estrutura gráfica (por exemplo, quando o utilizador move a janela gráfica ou percorre o histórico).
Muito provavelmente, por simplicidade e fiabilidade, um único objecto de sincronização é utilizado para a sua estrutura de dados gráfica.
Pode tentar melhorar a velocidade de execução usando "segmentação de dados", mas por outro lado, agora pode deparar-se com bloqueios, ou dados subactualizados, ou abrandamentos noutras áreas mais críticas.
Em geral, é melhor não tocar em algo que já esteja a correr bem.
Tem alguma incompreensão dos termos assíncrono e síncrono.
Quando se diz que uma função é assíncrona, significa que será executada não no fio da execução actual, mas em algum outro fio.
Chamar uma função assíncrona como ChartSetInteger a partir do fio principal é rápido, uma vez que a execução propriamente dita ocorre num fio diferente.
Por outro lado, uma chamada de uma função síncrona ChartGetInteger exigirá a sincronização dos fios e isto pode exigir tempo adicional.
O atraso é especialmente visível quando o fio paralelo está constantemente a actualizar os dados da estrutura do gráfico (por exemplo, quando o utilizador move a janela do gráfico ou percorre o histórico).
Muito provavelmente, por simplicidade e fiabilidade, um objecto de sincronização é utilizado para a sua estrutura de dados gráfica.
Pode tentar melhorar a velocidade de execução usando "segmentação de dados", mas por outro lado, agora pode deparar-se com bloqueios, ou dados subactualizados, ou abrandamentos noutros locais mais críticos.
Em suma, é melhor não tocar em algo que já esteja a funcionar de forma estável.
O seu direito, mas parece haver alguns engarrafamentos. O mercado está agora fechado, executei o código abaixo em 1 gráfico, nada mais funciona. Está a correr num VPS com apenas MT5 a correr e não interagi com o gráfico / MT5 com nada mais do que uma captura de ecrã. Tempo em µs, 127 µs em média, mas o pico é de 43.995 µs.
Cavalheiros desenvolvedores!
Por favor, corrijam-me se tiver escrito no fio errado. Há sugestões para facilidade de utilização e depuração, que penso que serão úteis para muitos, e para mim são importantes.
1. Aumentar o comprimento da linha OBJPROP_TOOLTIP para objectos (2 vezes é suficiente). Para estratégias com muitos gráficos, o comprimento actual é muito curto. Para a depuração, é necessário gastar tempo cada vez que se encaixam todos os dados necessários. Depois tem de mudar e/ou acrescentar reduções para os consumidores numa base regular.
2. Aumentar a duração dos comentários para os nomes dos parâmetros de entrada (2 vezes é suficiente). Os comentários aos parâmetros de entrada são necessários para o consumidor. E se houver um grande número, é também conveniente fazer uma numeração adicional. Para a optimização, é importante saber o nome da variável. Como resultado, muitas vezes não é possível encaixar tudo no comprimento actual. Exemplo:
3. Para variar a selecção de colunas na tabela de resultados da optimização até à exibição de tudo desdeENUM_STATISTICS e deixar o utilizador escolher o que precisa. Esta é uma escolhamuito pobre para análise. O drawdown em % é inútil durante a optimização com um volume fixo. Não há possibilidade de escolher o saque máximo em termos de moeda e depósito. Por vezes existe uma forte tendência entre posições de compra e venda durante a optimização, mas só se pode aprender sobre isso depois de executar um único teste. Muitas vezes temos de introduzir os parâmetros em falta no campo de resultados(STAT_CUSTOM_ONTESTER). Mas queremos exibir aí critérios de resultados adicionais, e é possível exibir apenas um, que ainda poderíamos suportar, se tivéssemos variado o número de colunas de critérios padrão daENUM_STATISTICS. Tudo somado, tenho de gastar muito tempo extra em super-optimização e análise.
Obrigado!
O seu direito, mas parece haver alguns engarrafamentos. O mercado está agora fechado, executei o código abaixo em 1 gráfico, nada mais funciona. Está a correr num VPS com apenas MT5 a correr, e não interagi com o gráfico / MT5 com nada mais do que uma captura de ecrã. O tempo é em µs, 127 µs em média, mas o pico é de 43.995 µs.
Vou assumir que o pico é a renderização do comentário do gráfico, caso contrário, quando a fila do gráfico está vazia, a chamada da função ChartGetXXX (note a chamada com sincronização) demora 0,13 milissegundos
Tem alguma incompreensão dos termos assíncrono e síncrono.
Quando se diz que uma função é assíncrona, significa que será executada não no fio da execução actual, mas em algum outro fio.
Chamar uma função assíncrona como ChartSetInteger a partir do fio principal é rápido, uma vez que a execução propriamente dita ocorre num fio diferente.
Por outro lado, uma chamada de uma função síncrona ChartGetInteger exigirá a sincronização dos fios e isto pode exigir tempo adicional.
O atraso é especialmente visível quando o fio paralelo está constantemente a actualizar os dados da estrutura do gráfico (por exemplo, quando o utilizador move a janela do gráfico ou percorre o histórico).
Muito provavelmente, por simplicidade e fiabilidade, um objecto de sincronização é utilizado para a sua estrutura de dados gráfica.
Pode tentar melhorar a velocidade de execução usando "segmentação de dados", mas por outro lado, agora pode deparar-se com bloqueios, ou dados subactualizados, ou abrandamentos noutros locais mais críticos.
Em geral, é melhor não tocar em algo que já esteja a correr bem.
Se pressionar o botão PrtScr e mover a janela do gráfico, isso causa atrasos horríveis de até 5 segundos.
No entanto, se apenas tirar uma imagem da janela do programa terminal.exe com ALT + PrtScr, não há qualquer atraso.
A julgar pelo serviço VPS integrado, há alguma experiência.
Vou assumir que o pico é a renderização do comentário do gráfico, caso contrário, quando a fila do gráfico estiver vazia, a chamada para a função ChartGetXXX (nota, a chamada com sincronização) demora 0,13 milissegundos
Não, Ilyas, parece que não há comentários no gráfico. Vou usar os registos e afixar.
Edição: Aqui está o resultado, nenhuma interacção com o gráfico ou MT5 ou Windows, após a sua execução, excepto para copiar os registos. Apenas 1 gráfico, nenhum outro software a correr no sistema. O pico é menor, mas ainda assim muito importante em comparação com a média. (µs)
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Número = 7440
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Min = 37
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Max = 17776
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Avg = 147
Não, Ilyas, parece que não comenta o gráfico. Vou utilizar os registos e afixá-los.
Edição: Aqui está o resultado, sem interacção com o gráfico ou MT5 ou Windows, uma vez iniciado, excepto para copiar os registos. Apenas 1 gráfico, nenhum outro software a correr no sistema. O pico é menor, mas ainda assim muito importante em comparação com a média. (µs)
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Número = 7440
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Min = 37
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Max = 17776
2020.06.13 07: 11: 25.192 342152 (EURGBP, H1) Avg = 147
Actualização :
O pico máximo agora aumentou seriamente:
2020.06.13 08: 18: 25.187 342152 (EURGBP, H1) Max = 23520
2020.06.13 08: 18: 25.187 342152 (EURGBP, H1) Min = 33
2020.06.13 08: 18: 25.187 342152 (EURGBP, H1) Max = 81011
2020.06.13 08: 18: 25.187 342152 (EURGBP, H1) Avg = 149