Fazendo um projeto de crowdsourced em Tela - página 33
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
Nesse exemplo, a taxa de atualização é normal. É por isso que não desacelera.
Em Task Manager eu vejo Metatrader(32 bit)
A questão do processamento assíncrono de dados foi resolvida?Pode ser a razão de seus atrasos estar relacionada com o tamanho do bit?
Porque agora o Metatrader foi projetado apenas para x64.
E, segundo os desenvolvedores, as versões de 32 bits não serão mais lançadas.
Eu vejo Metatrader(32 bit) em Task Manager
E a questão do processamento assíncrono de dados foi resolvida?Talvez, o motivo da lentidão esteja ligado à capacidade de dígitos do seu sistema?
Bem, o Metatrader agora é destinado apenas para x64.
E de acordo com os desenvolvedores, as versões de 32 bits não serão mais lançadas.
Confirmo que o exemplo de Nikolai que mencionei carrega a CPU ao mover qualquer um dos objetos do exemplo, especialmente se feito rapidamente. A carga aumenta em 35-40%. O teste foi conduzido em um processador de 64 bits, Windows 7 de 64 bits e MT5 de 64 bits.
O que se entende por processamento assíncrono em nossa discussão?
Eu posso ver Metatrader(32 bit) em Task Manager.
E a questão do processamento assíncrono de dados foi resolvida?Talvez, a razão de seus atrasos esteja na capacidade de dígitos de bits do sistema?
Na verdade, o Metatrader agora é personalizado apenas para x64.
E de acordo com os desenvolvedores, as versões de 32 bits não serão mais lançadas.
Todos estes exemplos estão no MT4.
O MT5 puxa muito mais, mas com um redesenho errado (por exemplo, um copo) ele também carrega o processador (eu verifiquei). O problema está na freqüência e na área de redesenho, que deve ser reduzida por todos os meios. Se você precisar redesenhar uma célula, então é a única célula. Caso contrário, é um desperdício de recursos (se, por exemplo, uma célula precisar ser redesenhada 10 vezes por segundo, então redesenhar toda a tela "matará" o processador e será irrealista). No entanto, já está claro.
Deixe-me explicar. Uma célula de tabela tem três objetos - base, texto e ícone. Se o conteúdo de uma célula mudar, precisamos fazer três loops da tela. No primeiro ciclo, redesenhamos a base, no segundo ciclo - o texto, no terceiro - o ícone. É como se tivéssemos triplicado a área da célula. Se você continuar desenhando novamente todo o kanvas nesta veia, você terá uma séria desaceleração. Portanto, deve-se levar em conta o número de ciclos na área da tela a ser redesenhada. Você pode não vê-lo em simples primitivos, mas ele se torna aparente em elementos complexos. Alguns elementos compreendem 10 objetos(uma caixa de entrada com botões ou uma lista de saída ou uma plataforma de janela) e é possível calcular quantos ciclos em uma matriz de kanvas devem ser feitos ao repintura-los. Felizmente, este redesenho não requer uma alta taxa de repetição.
O problema do processamento assíncrono não foi resolvido. Havia algumas idéias, mas ainda não foi encontrada uma solução.
Em geral, se quisermos criar uma GUI sobre tela, devemos fazê-la a partir de elementos redesenháveis separadamente. Caso contrário, o programa atingirá rapidamente o limite e depois disso os atrasos em operações simples serão perceptíveis.
O que se entende por processamento assíncrono de dados em nossa discussão?
Bem como eu o entendo em palavras simples, assíncrono (busca de recursos) ou multi-tarefa (recurso dedicado).
Eu não olhei para o código dos exemplos do Nikolay, mas devido à ausência de assincronia e multithreading noMetatrader, o código de redesenho de pixels é executado de forma síncrona.
E o processamento de dados de saída da Petera também é muito provavelmente realizado de forma síncrona. E em ambos os casos é provável que tudo isso ainda seja processado em ciclos.
Isto aumenta a carga sobre o processador. Para uma resposta rápida com menos carga de cada vez, o processamento de dados e o redesenho devem ser paralelos.
Bem, como eu o entendo em palavras simples, assíncrono (corrida de recursos) ou multithreading (recurso dedicado).
Eu não olhei para o código dos exemplos do Nikolay, mas devido à ausência de assincronia e multithreading noMetatrader, o código de redesenho de pixels é executado de forma síncrona.
E o processamento de dados de saída da Petera também é muito provavelmente realizado de forma síncrona. E, em ambos os casos, tudo isso é susceptível de ser processado em laços.
Isto aumenta a carga sobre o processador. Para uma resposta rápida com menos carga de cada vez, o processamento de dados e o redesenho devem ser paralelos.
Nem por isso)) Deixe-me esclarecer: eu tenho o motor conectado ao aplicativo do usuário através de um recurso. Ou seja, - a aplicação do usuário faz seus cálculos em sua rosca, e passa os dados para o motor (portando a GUI), que pode estar em um gráfico diferente. Isto lida com eventos de parâmetros e os envia para a GUI. Em outras palavras, o processamento é dividido em dois fios. No entanto, este não será o caso no construtor que vou postar. A aplicação incluirá o motor dentro de si e tudo estará em uma única linha. Mas a carga sobre o processador será a mesma. A dependência da velocidade na seqüência de funções simplesmente irá aumentar.
Nem por isso)) Deixe-me esclarecer: eu tenho o motor conectado ao aplicativo do usuário através de um recurso. Ou seja, - a aplicação do usuário faz seus cálculos em sua rosca, e passa os dados para o motor (portando a GUI), que pode estar em um gráfico diferente. Isto lida com eventos de parâmetros e os envia para a GUI. Em outras palavras, o processamento é dividido em dois fios. No entanto, este não será o caso no construtor que vou postar. A aplicação incluirá o motor dentro de si e tudo estará em uma única linha. Mas a carga sobre o processador será a mesma. A dependência da velocidade na seqüência de execução das funções será simplesmente maior.
aqui vamos nós novamente... promessas, anúncios, tagarelice.
mesmo já esquecido - "kernel-engine" foi publicado como um software decente ? ou como porcaria na forma de anexos aos comentários
Bem, como eu entendo em termos simples, assíncrono(raça de recursos) ou multithreading(recurso dedicado).
Não olhei para o código de exemplos do Nikolai, mas devido à ausência de assincronia e multithreading noMetatrader, o código de redesenho de pixels é executado de forma síncrona.
E o processamento de dados de saída da Petera também é muito provavelmente realizado de forma síncrona. E, em ambos os casos, tudo isso é susceptível de ser processado em laços.
Isto aumenta a carga sobre o processador. Para uma resposta rápida com menos carga de cada vez, o processamento de dados e o redesenho devem ser paralelos.
Todas as operações na MT são estritamente sincronizadas e isto não pode ser realmente alterado a menos que os desenvolvedores adicionem fios à aplicação.
É bastante surpreendente que os desenvolvedores estejam tentando expandir a funcionalidade MT em termos de trabalho com bancos de dados, com python, com sharpe... mas eles se oferecem para fazer tudo na mesma linha... É simplesmente incrível.
aqui vamos nós novamente ... promessas, anúncios, tagarelice
Eu até esqueci - o "kernel-engine" foi publicado como um software decente ? ou como porcaria, como anexos aos comentários
Bom para você. Eu me inspiro em lutar com pessoas como você, e elas sempre perdem)). Você está me dando energia e não se dá conta disso.
aqui vamos nós novamente ... promessas, anúncios, tagarelice
Eu até esqueci - foi o "kernel-engine" publicado como um software decente ? ou como porcaria na forma de anexos aos comentários
Max, seja discreto.
Nem por isso)) Deixe-me esclarecer: eu tenho o motor conectado ao aplicativo do usuário através de um recurso. Ou seja, - a aplicação do usuário faz seus cálculos em sua rosca, e passa os dados para o motor (portando a GUI), que pode estar em um gráfico diferente. Isto lida com eventos de parâmetros e os envia para a GUI. Em outras palavras, o processamento é dividido em dois fios. No entanto, este não será o caso no construtor que vou postar. A aplicação incluirá o motor dentro de si e tudo estará em uma única linha. Mas a carga sobre o processador será a mesma. É que a dependência da velocidade na seqüência de funções será maior.
Eu entendo o ponto, aplicação separadamente, GUI separadamente.
Mas o processamento dos dados de saída na GUI é realizado de forma síncrona de qualquer forma.
Por exemplo, a aplicação envia 10000 elementos para a GUI e a GUI processa todos esses elementos sequencialmente.
Este é o problema. É necessário paralelizar o processamento dos elementos recebidos e sua saída na GUI. Base, texto, ícone.
Mais ainda, há três ciclos por célula.