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
Por favor, dê um código de diagrama rudimentar para esta idéia. À primeira vista, parece um completo mal-entendido.
Durante a execução da função OnMain, não há como saber o estado da fila real atual. A única solução para fazer isso é um programa de spyware, como indicado no link.
Em sua forma mais simples:
Basta mudar a abordagem dos cálculos propriamente ditos (fazer o retorno intermediário com a freqüência que a tarefa exigir). Mas se for difícil, considere no passo 1 que OnMain não existe para você (você move o código principal não em OnMain, mas em On2XX), respectivamente, em OnMain você não precisa aprender nada
As muletas estão sendo feitas na direção errada:
Deixe as funções OnXXX apenas copiando eventos (parâmetros) na fila e chamando a principal função OnMain. Mova todos os seus códigos para duplicar as funções On2XX. E chame estas funções de duplicação On2XX da OnMain na seqüência em que você precisa, passando por sua vez os dados das filas como parâmetros.
Em seguida, execute as medições e mostre o ganho de velocidade, e então você pode sugerir complementar a MQL com a funcionalidade apropriada. Mas por que acrescentar, se você mesmo já fez tudo aqui e agora?
Não é sobre isso que você está escrevendo.
O problema é que a funcionalidade de preenchimento de campos nas variáveis de entrada da função "OntaredeTransaction" não corresponde à descrição dada no Help, para pior:
ou seja, muitos campos não são preenchidos nas chamadas e até mesmo na chamada final de TRADE_TRANSACTION_HISTORY_ADD.
Consequentemente, todos os comerciantes estão agonizando aqui para determinar de alguma forma estes parâmetros em falta no momento da chegada.
Houve muitas discussões aqui, basta fazer uma pesquisa no fórum - a funcionalidade pobre da "OntaredeTransaction" causa despesas adicionais tanto em tempo quanto em "cargas" comerciantes com tempo extra gasto no desenvolvimento de código de trabalho adequado (ou seja, enormes perdas de tempo e ineficácia colossal a nível comunitário).
As respostas atuais dos desenvolvedores como "Se você tem um símbolo de execução do mercado, ele terá valor zero de preço; deve ser assim" (Link).(Link) - isto é UNNORMAL, mais uma vez -
falta de valores exaustivos na última chamada de função leva a muito trabalho extra.
HistóriaSelect.
Esta é uma característica insanamente cara. E infelizmente, nenhuma quantidade de caching pode tornar sua velocidade aceitável agora.
Por exemplo, no campo de batalha EAs, é importante trabalhar com dados reais. Em particular, que os carrapatos do Market Watch e CopyTicks não estejam desatualizados, se possível.
Para fazer isso, não existem mecanismos muito bons, mas mecanismos forçados para verificar a relevância dos dados de preços atuais. Uma parte deste mecanismo é detectar situações em que um comércio sobre um símbolo tenha passado mais tarde do que o último tick. Isto não acontece raramente, portanto é importante saber se o tique atual ainda está atualizado ou não.
Para esta detecção, você precisa poder acessar o histórico dos negócios recentes. É feito usando o HistorySelect da seguinte forma esquemática.
Infelizmente, tal chamada da HistorySelect leva 5-30 milissegundos (eu mesmo a medi no ReleaseEX5). Quando o Expert Advisor faz várias dessas atualizações no OnTick (deve ser feito após qualquer pausa, por exemplo, após cada OrderSend), então tudo se torna insanamente caro/longo. HistorySelect pode comer coletivamente vários segundos em um único OnTick.
Caros desenvolvedores, por que é tão caro? Esta função pode ser executada instantaneamente com a devida implementação.
Você tem provas sobre "tal chamada à HistorySelect dura 5-30 milissegundos"?
Se eu entendi sua idéia corretamente, então o código de teste deve se parecer com isto:
É assim que funcionam as 100.000 consultas:
Você tem provas sobre "tal chamada à HistorySelect dura 5-30 milissegundos"?
Se entendi seu ponto de vista corretamente, então o código de teste deve ser parecido com este:
É assim que funcionam 100.000 consultas:
Você tem provas sobre "tal chamada à HistorySelect dura 5-30 milissegundos"?
Se entendi seu ponto de vista corretamente, então o código de teste deve ser parecido com este:
É assim que funcionam 100.000 consultas:
Executando seu roteiro.
Lançar outro roteiro.
Contagem normal de batalha. Não HFT.
A propósito, seu roteiro mostrou que a HistorySelect recalcula tudo a cada vez. E os parâmetros de entrada não mudaram, a tabela do histórico não foi atualizada, outras funções do HistorySelect não foram chamadas.
Executando seu roteiro.
Então, detalhes são necessários.
Meu teste não foi o mais rápido "Intel Xeon E5-2630 v4 @ 2,20GHz", com muitos outros processos em segundo plano.
A conta teste tinha 31315 pedidos em sua história mais ou menos uniformemente desde 2009, incluindo 8 pedidos para hoje.
Talvez, você tivesse algum script ou consultor especializado rodando ao mesmo tempo, causando um carregamento drástico dos bancos de dados do terminal. Experimente-o em um terminal "limpo".
Teste mais informativo:
Três corridas:
Então, detalhes são necessários.
Meu teste não foi o mais rápido "Intel Xeon E5-2630 v4 @ 2.20GHz", com muitos outros processos em segundo plano.
A conta teste tinha 31315 pedidos em sua história mais ou menos uniformemente desde 2009, incluindo 8 pedidos para hoje.
Talvez, você tenha tido algum script ou Expert Advisor rodando ao mesmo tempo, o que carregou drasticamente as bases de dados do terminal. Experimente-o em um terminal "limpo".
Terminal vazio sobre a mesma conta e máquina.
Em outras contas e Terminais o mesmo quadro. Configuração.
Peço aos leitores que dêem seus resultados deste roteiro.
Um teste mais informativo:
Três partidas:
Terminal Vazio 2460.
ZS Funciona em conta vazia.
A velocidade parece ser fortemente influenciada pelo número de negócios e não pelas ordens.
Terminal Vazio na mesma conta e máquina.
Em outras contas e Terminais, o mesmo padrão. Configuração.
Peço aos leitores que citem seus resultados deste roteiro.
Não prova nada, mas o fato de que a cada nova corrida (em um símbolo diferente), o tempo aumenta - é alarmante...
Necessidade de operar em uma conta com um longo histórico comercial.