Características da linguagem mql5, subtilezas e técnicas - página 102
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
Estás a ir longe demais ) Antes de mais nada, passa pela fila de mensagens. Em segundo lugar, você tem que fazer algumas conversões adicionais (para frente e para trás). Além disso, há alguma validação em curso.
A propósito, não se deve especificar explicitamente o tamanho da estrutura. Há tamanho para isso.
Talvez tenhas olhado para outro código.
HH a única coisa que eu não gosto na minha versão: eu tive que dobrar o tamanho da linha para contornar zeros, porque zero é percebido como o fim da linha. Sinto na minha espinha dorsal que há uma solução mais simples, mas ainda não a encontrei. Mas ainda funciona mais rápido.
SetWindowText/GetWindowText não são enviados através de mensagens?
Não há conversões de ida e volta.
Claro que sim. Porquê tanto alarido?
SetWindowText/GetWindowText não são enviados através de mensagens?
E você está falando de mensagens do Windows... E daí? Existe uma alternativa mais rápida para trocar dados entre diferentes programas no windos sem a dll homebrew?
Compreendo que se ofendeu com as minhas palavras, que a minha variante é rápida. Bem, primeiro, eu não o afirmei, apenas o sugeri. Em segundo lugar, eu apoiei minha suposição com o código de teste, comparando-o com oMemory Mapping.
E se você tentar refutar até mesmo suposições, por favor não baseie sua refutação apenas em declarações declarativas. Eu ficarei muito grato se você puder me dissuadir e apontar para a implementação mais rápida da troca de dados entre terminais sem nenhuma dll auto-gravada.
Eu não excluo que a variante via disco RAM seja muito mais rápida. Mas este é um tópico ligeiramente diferente, pois requer a instalação do disco RAM e sua configuração.
Claro que sim. Mas o que é esta dança com pandeiros:
Lá se vão os tamborins. É uma banalidade. E esta trivialidade, aliás, é realizada em 50-60 ns, quando todos os blocos de recepção da estrutura do tick são realizados em 90 µs (90 000 ns.), ou seja, estes "diamantes" ocupam apenas 0,06 % do tempo de recepção do bloco de dados. Além disso, escrevi que este ponto só me confunde em vista da duplicação da memória.
E assim a minha variante parece muito conveniente, simples e inteligente para a troca de pequenas estruturas de dados.
Fórum sobre negociação, sistemas de negociação automatizados e testes estratégicos
Bibliotecas: HistoryTicks
Automated-Trading, 2018.03.29 11:09
Uau!
Eu nem sabia de funções como CryptEncode eCryptDecode. Obrigado!
Vou dar uma olhadela nisso.
Mas enquanto à primeira vista tudo parece ser de alta tecnologia, mas insanamente lento, porque a função CryptEncode corre duas ordens de magnitude mais lentamente (microssegundos vs. dezenas de nanossegundos) do que o que foi aqui designado como pandeiros:
Presumo que se ofendeu por eu ter dito que a minha versão era rápida. Bem, primeiro, eu não o afirmei, apenas fiz uma suposição. Em segundo lugar, eu apoiei minha suposição com o código de teste, comparando-o com oMemory Mapping.
Não me referia à "rapidez", mas sim a"talvez seja mais rápido do que todas as soluções existentes", por isso fiz várias observações sem nenhum ataque. E essas observações foram bastante justas. Mas você, por alguma razão, primeiro nega-o persistentemente ("talvez você deva terolhado para algum outro código") e depois entra no "e daí! Então vamosseparar as moscas das costeletas.
Segundo, em relação ao MemoryMapping (mais precisamente, seu MQL-wrapper para ser mais preciso), eu nunca disse nada sobre ser rápido. Além disso, no tópico de discussão deste projecto , apontei os bugs de autor que criam desfasamentos e como corrigi-los. Portanto, se você vai testar algo, teste-o em sua forma nativa, e não na forma de decisões erradas de outra pessoa.
ZZY Mas enquanto à primeira vista é tudo alta tecnologia, mas insanamente lento, porque a função CryptEncode é duas ordens de magnitude mais lenta (microssegundos vs. dezenas de nanossegundos) do que o que é chamado aqui de pandeiros:
Para que serve a velocidade?
Não estou a falar de "rapidez", mas de"pode ser mais rápido do que todas as soluções existentes", por isso fiz algumas observações, sem qualquer ataque. E essas observações foram bastante justas. Só que você teima em negá-lo por alguma razão primeiro ("talvez você olhou para algum outro código"), e depois você entra na posição "e daí! Então vamosseparar as moscas das costeletas.
Primeiro, meu post foi escrito antes de você citar seu código de teste. Segundo, em relação ao MemoryMapping (mais precisamente, seu MQL-wrapper mencionado), eu nunca afirmei que ele funciona rápido. Além disso, no tópico de discussão deste projecto, apontei aqui os bugs de autor que criam desfasamentos e como corrigi-los. Então, se você vai testar algo, teste-o na forma nativa, não as decisões erradas de alguém.
Está bem. De acordo. Isso foi muito alto.
Eu só queria dizer, que possivelmente usar o user32.dll ao invés do kernel32.dll pode acabar sendo mais rápido ao ligar dois terminais via WinAPI, já que todas as implementações que eu encontrei usaram o kernel32.dll.
Para que é a velocidade?
Desculpe, não percebi a pergunta.
Você está perguntando - por que você precisa da velocidade da ponte entre terminais?
Desculpe, não percebi a pergunta.
Você está perguntando - por que você precisa de velocidade de troca de dados entre terminais?
Sim.
Fórum sobre negociação, sistemas de negociação automatizados e teste de estratégias de negociação
Peculiaridades da linguagem mql5, dicas e truques
Nikolai Semko, 2018.09.21 13:20
Mas até agora, à primeira vista, tudo isto, claro, de alta tecnologia, mas insanamente lento, porque a função CryptEncode é executada duas ordens de magnitude mais lenta(microssegundos vs. dezenas de nanossegundos) do que o que é chamado aqui de pandeiros: