![MQL5 - Linguagem para estratégias de negociação inseridas no terminal do cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Yedelkin:
Da mesma forma, se já existe um evento ChartEventem fila de mql5-programa ou tal evento está a ser tratado, então um novo evento desse tipo não está em fila de espera".
Hmm. Isto é realmente mau. Teoricamente significa que se, por exemplo, um indicador e um Expert Advisor utilizarem eventos de forma independente, então pode haver saltos em ambos os casos.
Então não vale a pena utilizar o evento como uma forma fiável de transferência de dados.
É uma pena.
A sua pergunta "com que frequência aproximada os eventos personalizados devem ser enviados para que não transbordem a fila".
A minha resposta na primeira página é "com a frequência das chamadas OnChartEvent".
Ou seja, um evento é um OnChartEvent. Não deve haver mais do que dois eventos no meio.
Isso é tudo matemática.
Mais uma vez, leia a primeira página. Mostrei como evitar a acumulação de eventos do utilizador quando o evento terminal é processado em vez do evento do utilizador. É tão simples quanto isso.
Mais uma vez, educadamente :) Você resolveu o seu problema, eu estou a tentar resolver o meu, de um plano diferente. Ao ler a discussão, não encontrei uma resposta às minhas perguntas. Ainda não respondeu à minha pergunta principal (sobre o uso da memória) (se assim o desejar).
Deixem-me explicar. Não tenho a tarefa "de actualizar alguma função, mas mais rapidamente do que a MQL sugere utilizando um temporizador". Ainda mais de uma forma tão inteligente que foi sugerida no final. Os eventos personalizados de vários gráficos com bombardas de frequência variável um gráfico separado contendo a função Expert Advisor e event handler. Assim, o resultado da sua tarefa estritamente focalizada(EventChartCustom dentro da OnChartEvent) não se enquadra de modo algum no meu esquema de trabalhar com eventos personalizados.
Yedelkin:
Para esclarecer. Não tenho a tarefa de "fazer alguma actualização de funções mais rapidamente do que a MQL sugere por temporizador". Especialmente não de uma forma tão inteligente, como sugerido no final. Os eventos personalizados de vários gráficos com bombardas de frequência variável um gráfico separado contendo a função Expert Advisor e event handler. Assim, o resultado da sua tarefa estritamente focalizada(EventChartCustom dentro da OnChartEvent) não se enquadra de modo algum no meu esquema de trabalho com eventos personalizados.
não é complicado, é simples. Se não consegue compreendê-lo, o problema não é meu. esse é um
Não está dentro do OnChartEvent, está disperso por todo o código. Está a inventar as suas próprias restrições estreitas ao seu funcionamento. são duas.
Do mesmo modo, se já houver um evento ChartEvent na fila de mql5-programa ou se um tal evento estiver a ser tratado, um novo evento deste tipo não será colocado na fila.
Isto ou é um erro de bug ou de documentação ou condições em falta.
Os eventos são todos enfileirados com sucesso e nenhum evento é descartado. Caso contrário, o meu tópico não teria aparecido.
Estou a tentar resolver o meu outro problema
que efeito tem o excesso de filas de eventos no tamanho da RAM? Se a fila de eventos se revelou estar a transbordar, para onde vão os eventos que transbordaram a fila?
Se um evento é descartado, então simplesmente não é enfileirado. A memória não está a crescer.
Phew! Isso é o principal que eu queria compreender. E como TheXpert disse que apenas alguns MB são gastos na própria fila, é provável que a fuga de memória esteja noutro lugar... Vamos avançar com essa declaração até prova em contrário.
Se este tipo de problema ocorrer, então as coisas são muito más. Penso que a fila de eventos a transbordar é o último lugar a procurar problemas de memória.
Sim, tentando procurar em todo o lado que posso.
Mas note-se que dos três peritos desqualificados, pelo menos dois estavam a trabalhar com um fluxo de eventos personalizados (o autor do terceiro não responde ao pedido). Lizar (trabalhando com eventos personalizados) também tem um elevado uso de memória. E tol64 tem um consumo de memória extremamente baixo porque os eventos do utilizador são utilizados com menos frequência do que uma vez por minuto, se eu tiver acertado. Assim, acontece que terá de duvidar da eficácia da implementação do conceito de eventos personalizados, intencionalmente a nulo. Até obter uma resposta exaustiva.
Mas note-se que dos três EAs desqualificados, pelo menos dois estavam a trabalhar com um fluxo de eventos personalizados (o autor do terceiro não responde ao pedido). Lizar (trabalhando com eventos personalizados) também tem um elevado consumo de memória. E tol64 tem um consumo de memória extremamente baixo porque os eventos do utilizador são utilizados com menos frequência do que uma vez por minuto, se eu tiver acertado. Assim, acontece que terá de duvidar da eficiência da implementação do conceito de eventos personalizados, voluntariamente a zero, até obter uma resposta exaustiva.
não é complicado, é simples. Se não o conseguirem compreender, o problema não é meu.
Tal como o entendi, escrevi que é complicado. Caso contrário, não lhe teria tocado.
Não está dentro do OnChartEvent, está em todo o código. Está a inventar as suas próprias restrições estreitas sobre a forma como funciona. são duas.
Sim, sim, o EventChartCustom não está dentro do OnChartEvent, mas, tipo, no exterior. Agora veja o seu próprio código:
Obviamente neste código EventChartCustom não está dentro doOnChartEvent, e estou muito enganado :)
ou está errado ou é um bug ou um erro de documentação ou uma condição subestimada.
Todos os eventos permanecem com sucesso na fila e nenhum evento é descartado. Caso contrário, o meu tópico não teria aparecido.
Há pelo menos mais uma versão: no seu caso particular, a fila simplesmente não transborda (devido à eficiência do código), pelo que não há factos de descartar eventos.
Há pelo menos uma outra versão: no seu caso particular, a fila simplesmente não transborda (devido à eficiência do código), pelo que não há provas de descartar eventos.
Aqui está o meu caso particular, comecei a demonstrar não descartar eventos idênticos
https://www.mql5.com/ru/forum/5091#comment_112780
Escrevi aí porque é que o transbordo ocorre.
Sim, sim, o EventChartCustom não está dentro do OnChartEvent, mas, tipo, no exterior. Agora veja o seu próprio código:
Vá até à raiz! Mostrei uma demonstração do problema e da sua solução. Esta chamada do EventChart pode estar em qualquer parte do código.
E não esqueçamos o facto de que o Conselheiro Especialista recebeu os eventos dos indicadores que foram executados em muitas ferramentas e prazos, cerca de 80 no total, se bem me lembro. Cada indicador consome recursos para os amortecedores indicadores, e aí reside o cão.
Está a falar dos japoneses? Bem, no meu caso é mais simples: um indicador universal com 8 ou 15 buffers indicadores de cálculo, funcionando com 6 instrumentos de uma só vez. Ou seja, existem apenas 6 indicadores. Teoricamente, um tal esquema pode consumir 2 GB numa semana?
Leia o artigo Redução do Consumo de Memória dos Indicadores Auxiliares, pode ser útil.
Obrigado, já tenho tudo optimizado aí :) Incluindo com este artigo em mente, tanto quanto me lembro. Terei de esperar pelo próximo grau de esclarecimento :)
É possível determinar o Expert Advisor e o indicador separadamente, se trabalharem em conjunto através de eventos personalizados?