MT5 e velocidade em ação - página 23
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
No caso de alguém não conseguir, é a biblioteca do fxsaber que está causando a frenagem quando aplicado no código de outra pessoa.
Em vez de apontar isso explicitamente, ele começou a jogar o jogo sobre a frenagem da plataforma e a dar exemplos suicidas. E quando houve uma oportunidade de chegar à verdadeira causa e resolver o problema, ele não a aproveitou.
Em nome da otimização local estava envenenando o cache de histórico para a aplicação principal.Fórum sobre comércio, sistemas comerciais automatizados e estratégias comerciais de teste
MT5 e velocidade em ação
fxsaber, 2020.09.02 00:02
Havia um código MQL5 limpo e reprodutível por muitos. A cronologia do primeiro estudo, em vez de jogar a teoria da conspiração, de que alguém precisa tanto de você que está disposto a gastar seu tempo com você para o lama.
Você está fazendo um ótimo trabalho como um peru. Não houve aqui nenhuma discussão sobre nenhuma biblioteca especificamente no tópico, pois não é construtiva.
A questão é que se alguém se aventura a usar bibliotecas compartilhadas onde o parâmetro de entrada não coincide, ele terá freios. Não há nenhuma menção a isto em nenhuma parte da Documentação. Pelo menos algo sobre isso foi tirado de você com uma tenaz. E quando isso foi feito, eles começaram a acusá-lo de trapacear.
Esta característica da MQL deve ser escrita no ramo Documentação e Recursos. Execute os scripts MQL5 limpos deste ramo nos builds correspondentes às datas de sua criação. Aparentemente, tantos consertos foram feitos cegamente só por precaução.
Você está fazendo um ótimo trabalho como indie. Nenhuma biblioteca foi especificamente mencionada aqui no tópico, porque não é construtiva.
Porque você fez o melhor que pôde para não tagarelar sobre suas bibliotecas. Na presença dessas bibliotecas. Com a constante oposição do "meu é mais rápido". Assim, você disfarçou inteligentemente o tiro em si mesmo, destacando "veja como ele é lento".
A questão é que se ousarmos usar juntas bibliotecas onde o parâmetro de entrada não é o mesmo, teremos um atraso. Não há nenhuma menção a isto em nenhuma parte da Documentação. Pelo menos algo sobre este tópico foi extraído de você com uma tenaz. E quando isso foi feito, eles começaram a acusá-lo de trapacear.
Esta característica da MQL deve ser escrita no ramo Documentação e Recursos. Execute os scripts MQL5 limpos deste ramo nos builds correspondentes às datas de sua criação. Aparentemente, tantos consertos foram feitos cegamente só por precaução.
A documentação do HistorySelect afirma claramente:
Quando você está trabalhando com grandes volumes (e você mostrou milhares e dezenas de milhares de negócios na história por uma razão), que requerem acesso atômico/snapshot, você precisa entender o custo deles.
Especialmente desde que expliquei os detalhes técnicos destas caches em grande detalhe neste tópico.
Você já tentou por nada randomizar cada amostra e envenenar o cache o máximo possível? Para o bem de sua posição, qualquer auto-golpe está em ordem?
Porque você fez tudo o que pôde para manter suas bibliotecas em silêncio. É por isso que você habilmente mascarou os insetos auto-infligidos, exibindo "veja como é lento".
99% dos insetos são encontrados desta forma. Primeiro, o comportamento estranho é encontrado no grande código. Em seguida, a localização encontra a causa. Eu estava mais preocupado com os freios.
função comercial. Os problemas estão em quase todos os lugares.
A documentação do HistorySelect declara explicitamente:
Quem terá visto algo nas entrelinhas deste texto? Pessoalmente, entendi (antes deste ramo), que a HistoryDealSelect e a HistoryOrderSelect devem ser escritas assim.
Caso contrário, é garantido que você encontrará desfasamentos.
Quando se trabalha com grandes volumes, que requerem acesso atômico/snapshot, é preciso entender o custo deles.
Mais ainda desde que expliquei os detalhes técnicos destas caches em grande detalhe neste tópico.
Tenho coletado as informações necessárias neste tópico.
Você já tentou por nada randomizar cada amostra e envenenar o cache o máximo possível? Para o bem de sua posição, qualquer auto-golpe está em ordem?
Você pode ver tudo cronologicamente nesta linha. O problema foi mostrado originalmente sem nenhum randômio.
Este fio é uma grande prova de como você pode distorcer as palavras de seu oponente. Todas as fontes e seus resultados são salvos aqui.
Por que o terminal não pode simplesmente aumentar o cache quando o histórico completo é solicitado novamente, recuperar e armazenar em cache a faixa que falta? Isso parece resolver o problema. Afinal de contas, ao solicitar barras/tickets, os pacotes de dados em falta são devolvidos, portanto, existe um mecanismo para isso.
Por que o terminal não pode simplesmente aumentar o cache quando o histórico completo é solicitado novamente, recuperar e armazenar em cache a faixa que falta?
Isto já foi feito.
Mas se entre HistorySelect( 0, INT_MAX ) chamarHistorySelect( other_time, ... ), o cache será reconstruído a partir de other_time e o próximo pedido deHistorySelect( 0,... ) levará à construção de um novo cache (será mais lento).
Isto já foi feito.
Mas se entre chamadas de HistorySelect( 0, INT_MAX ) chamarmosHistorySelect( other_time, ... ), o cache será reconstruído a partir de other_time e o próximo pedido deHistorySelect( 0,... ) levará à construção de um novo cache (será mais lento).
Se você fez isso, é bom, a única questão é então sobre a conveniência do trabalho com os dados recebidos, desde que o cache seja construído.
Eu não entendi tão profundamente as operações comerciais, mas se o intervalo de consulta mudar, então não há possibilidade de pesquisar dados rapidamente dentro do histórico sem força bruta total?
Não estou muito envolvido no comércio, mas se o alcance da consulta mudar, então não há como procurar rapidamente por dados dentro da história sem uma enumeração completa?
Para que serve este conhecimento se você não o utiliza?
Sem problema prático = sem dúvida.
OrderExist e PositionExist são funções especiais otimizadas que evitam o estúpido looping por todos os pedidos ou posições em busca de entradas por símbolo, tipo de transação e medzhik.
O resultado é uma variedade de bilhetes.
Os programas podem economizar muito dinheiro usando estas funções. Especialmente ao chamar posições abertas e pedidos a granel, constante e repetidamente em loops em excesso.
Implementaremos funções mais eficazes para acessar dados comerciais massivos no futuro.
A linguagem também será drasticamente reforçada e simplificada com funcionalidades mais poderosas.
"OrderExist e PositionExist" - não encontrado na documentação, onde ler sobre eles?
Muito provavelmente após a próxima versão de lançamento (agora em beta)