MT5 e velocidade em ação - página 17
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
Observe que a HistorySelect faz uma foto física da história selecionada para o cache local da EA, de modo que você possa passar por eles sem medo. Sem isto você pode obter efeitos muito desagradáveis, pois o histórico da conta é atualizado/sincronizado de forma assíncrona. Sem mencionar o fato de que o próprio usuário pode alterar manualmente a profundidade da história a partir da interface.
Daí tais custos de cópia. Ainda mais se você tentar deliberadamente forçar a cópia deste histórico para o cache simultaneamente a partir de vários fios.
Já otimizamos muito nas operações de amostragem e agora estamos pensando na atualização ótima do cache, quando na realidade 99% das amostras serão completamente inúteis e serão puladas na mosca.
Ou seja, a menos que você randomize especificamente os limites de amostragem, o cache mostrará acessos próximos a 100%.
Muito provavelmente, na próxima semana já haverá uma solução eficaz.
Observe que a HistorySelect faz uma foto física da história selecionada para o cache local da EA, de modo que você possa passar por eles sem medo. Sem isto você pode obter efeitos muito desagradáveis, pois o histórico da conta é atualizado/sincronizado de forma assíncrona. Isto sem mencionar o fato de que o usuário pode mudar manualmente a profundidade da história a partir da interface.
Há uma tabela de pedidos e uma tabela de acordos. Por que precisaríamos fazer "snaps" físicos, quando conhecemos os quatro índices no momento da chamada da HistorySelect?
É por isso que os custos de cópia são tão altos. Especialmente se lidarmos especificamente com a cópia simultânea obrigatória deste histórico para o cache a partir de vários fios.
Já otimizamos muito nas operações de amostragem e agora estamos pensando na atualização ideal do cache, quando na realidade 99% das amostras serão completamente inúteis e serão puladas na mosca.
Ou seja, a menos que você randomize especificamente os limites de amostragem, o cache mostrará acessos próximos a 100%.
Muito provavelmente, na próxima semana já haverá uma solução eficaz.
HistóriaDealSelect e HistóriaOrderSelect destroem agora as amostras relevantes. Por que não temos, como no MT4, acesso a ambas as tabelas por índices? Introduzir novas funcionalidades.
Fórum sobre comércio, sistemas automatizados de comércio e teste de estratégias comerciais
Bichos, insetos, perguntas
fxsaber, 2020.08.20 11:28
Novas funções internas.Os índices estão pedindo por isso. Não entendo porque deveria saber o número de negócios em minha conta através de um único lugar.
E estas tabelas podem mudar a qualquer momento. Assim como os registros individuais neles podem ser feitos.
Ninguém pode garantir sua imutabilidade devido a operações assíncronas, processos de sincronização e modos manuais de profundidade definidos pelos usuários.
Como escrevi acima, aplicaremos técnicas de cache inteligente, o que reduzirá o custo das funções Select a zero. A menos, é claro, que você randomize especificamente os limites da amostragem. A última data pode ser alterada e não invalidará o cache se for sempre no futuro/último momento. Transações recentes serão poupadamente adicionadas ao cache.
No MT4 funciona da mesma maneira, apenas a criação de cache é escondida. Em cada OnTick/OnStart do MT4, o terminal cria automática e parcimoniosamente um instantâneo do ambiente de mercado para cada EA.
Portanto, você não pode avaliar a verdadeira latência da preparação dos dados a partir do código MQL4. Felizmente, no MT4, os dados são pequenos e simples.
Na MT5 desistimos dos custos de criação automática do ambiente de mercado para reduzir atrasos e não realizar trabalhos desnecessários. Em vez disso, demos controle total dos custos aos desenvolvedores de robôs que podem solicitar exatamente o que precisam.
Observe que o tamanho do ambiente de mercado no MT5 é enorme comparado ao MT4 - ele simplesmente não pode ser replicado.
Com seus testes, você aproveitou uma amostragem tão cara.
Vamos consertar isso - é do nosso interesse.
E estas tabelas podem mudar a qualquer momento. Assim como os registros individuais neles podem ser feitos.
Ninguém pode garantir sua imutabilidade devido a operações assíncronas, processos de sincronização e modos manuais de profundidade definidos pelos usuários.
Você está dizendo que antes do já último comércio, outro comércio pode aparecer na história do comércio? Se um comércio mudou, outro. Mas para cravar dentro de uma lista já existente - eu não notei isso.
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.
Você está dizendo que pode haver outro comércio na história do comércio antes do já último comércio? Se um acordo mudou, outro. Mas para cravar dentro de uma lista já existente - eu não notei isso.
Teoricamente, sim.
Não se esqueça dos processos de sincronização. Um grande número de processos na plataforma são assíncronos.
Por exemplo, uma integração de gateway com um provedor de câmbio ou liquidez pode enviar relatórios de transações com atrasos de segundos ou mesmo minutos. Muitas vezes a api não fornece acesso ao histórico para a reconciliação, mas fornece geradores de relatórios lentos e não rítmicos.
Na abertura do mercado, ou devido a uma reconexão inesperada do portal, os relatórios podem ser atrasados. Eles são replicados para o histórico no servidor e imediatamente enviados de forma assíncrona para os terminais. Por causa da classificação por data, eles são inseridos nos lugares certos e, enquanto isso, você pode abrir novos negócios.
A maioria dos APIs de integração são tão analfabetos e disfuncionais que quase impossibilitam a criação de gateways garantidos. Embora haja uma opinião de que se trata de um produto de sabotagem deliberada por seus desenvolvedores.
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.
Renat, um grande pedido para ter acesso às citações fora de TERMINAL_MAXBARS ao usar as funções Copy... Pelo menos um minuto de tempo. Você também pode fazer uma função separada para isto.
Mas para ter acesso a esses dados, você deve sempre definir TERMINAL_MAXBARS para ilimitado (além disso, sobrecarrega o terminal), o que é muito inconveniente porque você não precisa de ilimitado para todos os símbolos.
Tanto quanto sei, se você copiar todas as pequenas barras de período MN1, todas as barras M1 serão baixadas de qualquer forma, mas não há acesso a elas.
É claro que você pode baixar todos os carrapatos, porque eles não estão sujeitos a esta restrição, mas é mais demorado e, infelizmente, os carrapatos nem sempre coincidem com toda a história do minuto.
Renat, um grande pedido para ter acesso a citações fora do TERMINAL_MAXBARS ao usar as funções Copiar... Pelo menos um minuto de tempo. Você também pode fazer uma função separada para isto.
Mas para ter acesso a esses dados, você deve sempre definir TERMINAL_MAXBARS para ilimitado (além disso, sobrecarrega o terminal), o que é muito inconveniente porque você não precisa de ilimitado para todos os símbolos.
Afinal, tanto quanto sei, se você copiar todas as pequenas barras do período MN1, todas as barras M1 serão baixadas de qualquer forma, mas não há acesso a elas.
É claro que você pode baixar todas as carrapatas porque elas não estão sujeitas a esta restrição, mas é mais demorado e, infelizmente, as carrapatas nem sempre coincidem com todo o histórico de minutos.
Não, o histórico fora desses limites não é coletado e verificado para sincronização. Além disso, não há lugar para armazená-las (não construiremos caches invisíveis adicionais), não escalaremos o disco em modos não econômicos e não construiremos muletas.
De modo geral, esta é uma idéia prejudicial, pois os desenvolvedores começarão imediatamente a escrever algoritmos absolutamente ineficientes e aconselharão os comerciantes a "fixar 5000, ou melhor, 1000 barras" e nos acusarão de lentidão e ineficácia.
Permitimos propositadamente controlar a quantidade de recursos para os gráficos. São 64 bits e a memória é barata agora - use as configurações apropriadas dentro das regras e da arquitetura.
Não vamos mudar este comportamento.
Não, a história fora desses limites não é levantada e verificada para sincronização. Além disso, não há lugar para armazená-las (não construiremos caches invisíveis adicionais) e não subiremos sobre o disco em modos antieconômicos.
Na verdade, é uma idéia prejudicial, pois os desenvolvedores começarão imediatamente a escrever algoritmos absolutamente ineficientes e aconselharão os comerciantes a "fixar 5000 ou melhor 1000 barras" e nos acusarão de lentidão e ineficácia.
Permitimos propositadamente controlar a quantidade de recursos alocados aos gráficos. São 64 bits e a memória é barata agora - use as configurações apropriadas dentro das regras e da arquitetura.
Não vamos mudar este comportamento.
Ok. Entendi. Obrigado. riscado.
Embora, é claro, eu gostaria de discutir sobre antieconomia. Terei que deixar ilimitado e, como resultado, todos os gráficos abertos (por exemplo, tenho 14 gráficos no momento) manterão toda a história, embora eu só precise de 5000 para a maioria deles. O que, ao contrário, será mais antieconômico.
Também não preciso destes dados para ser armazenado. Eu me encarregarei do armazenamento. Iniciei o carregamento de todas as barras minúsculas, coloquei-as em uma matriz e não preciso mais delas e todas as caches podem ser apagadas se seu tamanho exceder TERMINAL_MAXBARS. Então talvez seja para isso que serve uma função separada que não armazena caches.
Embora, é claro, eu concorde que mãos malandrecas podem suspender o sistema com tais cargas periódicas.
Você só tem dois estados 5000 e um ilimitado?
Você é o mestre de sua própria felicidade.