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
Falando de intuição. Quero lhes dar um exemplo interessante. Meu post, impresso neste tópico https://www.mql5.com/ru/forum/95632/page12há mais de dois anos:
1. O conceito de um motor gráfico.
2. Conceito do núcleo gráfico.
3. estágios de criação do estúdio visual para a plataforma MT.
4. descrição do mecanismo de criação da interface EA.
Omotor gráfico é um programa projetado como um indicador. Este programa é projetado exclusivamente para a gestão da interface do usuário. Ele executa um conjunto de funções básicas:
O motor gráfico é adicionado a um gráfico como qualquer outro indicador . Ela inclui o seguinte conjunto de janelas:
Isto, em princípio, é o fim do conceito do motor gráfico. O importante é que sem ela a operação da interface é impossível.
Um mecanismo gráfico é um bloco de informações contendo dados de todos os objetos e janelas em uma interface, que é registrado em uma matriz e salvo em um arquivo.
Este bloco é uma representação digital da interface gráfica. Ele é carregado pelo motor gráfico a pedido do usuário. O próprio motor gráfico tem seu próprio kernel gráfico interno que assegura o funcionamento de suas próprias janelas, e espaço livre é fornecido dentro deste kernel para a integração da interface do usuário (na forma digital) com ele. A integração é realizada no processo de carregamento do núcleo gráfico a partir de um arquivo.
3. A criação de um estúdio visual na plataforma MT, como eu a entendo, está dividida em duas etapas:
4. Gostaria de delinear o mecanismo do processo de criação da interface e levantar um pouco o véu sobre sua tecnologia. Explique de onde vem a facilidade de criar uma interface através de um arquivo.
Este é o caso: o motor tem uma função especial que cria um kernel gráfico completo baseado em um único arquivo com uma quantidade mínima de informações de carga. As informações de inicialização neste arquivo são auto-explicativas e legíveis por humanos. É fácil de escrever e editar. Por exemplo, você precisa escrever "_CREATE_NEW_WINDOW" para criar uma janela, e "_CHECKBOX" e nome da caixa de seleção, (motor reconhece automaticamente o nome do elemento, como nome do próprio elemento e como nome de seu parâmetro).
Esta função é chamada de "G_CORE_BUILDER()" e constrói o núcleo gráfico tomando dados de duas fontes principais: um arquivo boot-up criado pelo usuário e a matriz "CONTENT[] " contendo todos os grupos padrão de objetos incluídos nas plataformas Windows e de controles. O "CONTEÚDO[] " também contém estados e scripts de objetos. Tudo em uma só matriz. Em geral, o material fonte do "CONTENT[]" + o arquivo carregador criado pelo usuário é usado por "G_CORE_BUILDER()" para construir o núcleo gráfico com o qual o motor trabalha.
É incrível o quanto os termos e conceitos NÃO mudaram em dois anos de trabalho árduo. E as funções e arrays e palavras-chave são como se diz aqui. Tudo foi implementado de acordo com este cenário. E esta tecnologia está funcionando e evoluindo, apesar dofato de que há dois anos atrás eu NÃO tinha nenhuma experiência no desenvolvimento de uma linguagem de marcação.
Não cheguei a um beco sem saída, não mudei o conceito, não mudei a direção. Continuei a criar o motor, o núcleo e a linguagem de marcação exatamente como eu pretendia inicialmente. E a prática confirma que o caminho que escolhi foi o certo.
Se isto não é intuição profética, então o que é?
Caros oponentes.
Aqui está o código do roteiro que:
Resultado:
Minha solução é mais de 10 vezes mais rápida.
Adicione à sua solução, o tempo para economizar o recurso e o tempo para colocar o recurso na matriz usando ResourceReadImage();
Na minha solução, nem a primeira nem a segunda são necessárias.
Minha solução é mais de 10 vezes mais rápida.
Peter, se você trabalhar com cordel, perderá o desempenho em qualquer caso. Portanto, é surpreendente ouvir você perseguir um desempenho mítico, mesmo que originalmente você tenha escolhido uma solução inadequada para ele: passar mensagens através de um fio e depois analisar essa mensagem.
Peter, se você trabalhar com cordel, perderá o desempenho em qualquer caso. Portanto, é surpreendente ouvir você perseguir um desempenho mítico, mesmo tendo escolhido originalmente uma solução inadequada para ele: passar mensagens através de um fio e depois analisar essa mensagem.
Vasily, de que outra forma você transfere dados de todos os tipos entre programas?
OnChartEvent() é parcialmente adequado.
E a propósito, medindo menos de 20 milissegundos, estritamente falando não é válido, pelo menos em sistemas com multithreading preemptivo. Mas mesmo que você aceite seu resultado (em geral eu o admito), ele ainda não lhe diz nada, porque o que importa são os custos do círculo completo. E o que você mediu é apenas parte dele.
Preciso de um caminho universal e o mais rápido. Para trabalhar no testador e contornar a fila de eventos OnChartEvent();
O teste mostra que a transferência através dos recursos é 10 vezes mais lenta. (sem medir o tempo para economizar recursos e obter dados a partir delesusando ResourceReadImage()) .
Minha solução é a melhor opção em condições iniciais.
...Mas mesmo que você aceite seu resultado (em geral eu o admito), ele ainda não lhe diz nada, porque o que importa são os custos do círculo completo. E o que você mediu é apenas parte dele.
É verdade, mas se você extrapolar para mais linhas e engrenagens, minha opção ainda ganha.
Vasiliy, de que outra forma você transfere dados de todos os tipos entre programas?
Mapeamento direto de estruturas através de matriz de bytes sindicalizados, compartilhados para acesso global. Não sei se isto é tecnicamente viável, mas se assim for, a velocidade será cósmica, pois não será preciso copiar nada.