Discussão do artigo "Diminuindo o Consumo de Memória pelos Indicadores Auxiliares"
A abordagem é compreensível. Mas a relevância da tarefa é confusa.
Embora um sistema de 64 bits ofereça suporte a grandes quantidades de RAM, a relevância da tarefa é insignificante. Até mesmo o sistema de 32 bits, com seus 3 Gb, consegue extrair tamanhos de memória como os que você está economizando. Afinal de contas, não importa como você olhe para ela, a memória cresce linearmente ao carregar novos indicadores, o que significa que 48 MB a mais ou a menos para computadores modernos não é nada.
Ok, vamos supor que a tarefa seja relevante (concordo que há pessoas que se importam com isso). Mas pense bem, a tarefa de economizar memória está em conflito direto com a tarefa de desempenho.
Portanto, você deve prestar atenção a esse ponto também.
Até onde posso ver do meu ponto de vista, os MQs estão lutando pelo desempenho e é aí que todos os esforços estão concentrados.
Se você precisar economizar recursos de memória em indicadores não desenhados, basta transferir o código do indicador para o Expert Advisor. Aqui você terá controle total sobre a memória alocada. Ao mesmo tempo, você poderá economizar no recebimento do mesmo tipo de dados. Muitos indicadores solicitam os mesmos dados, cada um para seu próprio processamento. Depois de receber os dados uma vez, você não precisará lidar com eles na próxima vez.
Agora vamos combinar a velocidade das tarefas e o tamanho da memória. A maioria dos indicadores que não são de desenho está envolvida no cálculo da última barra, o que é indicado pelos mecanismos internos de bloqueio do recálculo de toda a matriz. Acontece que, no Expert Advisor, será possível alocar 154 células de memória (por exemplo, para o cálculo da máscara com o período de 153) com essa economia de memória, o desempenho não será pior do que em um indicador regular.
Mas a possibilidade de paralelizar os cálculos é perdida no Expert Advisor, e isso é um golpe direto no desempenho. Na verdade, os indicadores consomem memória apenas por causa do paralelismo. Afinal de contas, cada indicador funciona em seu próprio thread e esse thread deve ter sua própria instância de dados de origem.
- www.mql5.com
Concordo, o desempenho é a principal prioridade e não faz sentido economizar memória (a menos, é claro, que você use mais de 1 Gb, o que é improvável).
A abordagem é compreensível. Mas a urgência da tarefa é confusa.
Bem, na verdade, a ideia de escrever este artigo veio à minha mente depois que uma pessoa, para quem escrevi um determinado indicador composto, reclamou que esse indicador não estava instalado em alguns pares. Ao investigar, descobri que há indicadores muito persistentes, e muitos deles não cabem no terminal (ou seja, o problema não estava no par, mas no fato de que, antes desse par, foi aberta uma dúzia de outros com o mesmo indicador persistente). Esse indicador consumia duas vezes mais do que o indicador de teste do artigo.
Até mesmo os 32 bits, com seus 3 GB, podem puxar bastante esses tamanhos de memória
Se você opera com um grande número de pares, isso não acontece, esse é o ponto.
A propósito, o terminal não pode alocar mais de 2 Gb de memória (no total: RAM + memória virtual). Em meus experimentos, ele fechou nessa marca.
É claro que esse problema não deveria existir em 64 bits.
OK, vamos supor que a tarefa seja relevante (concordo que há pessoas que se preocupam com ela). Mas pense bem, a tarefa de economizar memória contradiz diretamente a tarefa de desempenho.
Nem sempre. No artigo, aqui, a maioria dos métodos não reduz o desempenho.
Um Expert Advisor que solicita apenas a última barra dos indicadores é uma classe de programa diferente da considerada no artigo. E nem sempre é possível/conveniente substituir um pelo outro.
.
É improvável que cada indicador em um par comum tenha sua própria instância de dados - há uma tabela interessante no artigo sobre cálculos paralelos, que pode ser encontrada pela frase-chave "2 indicators".
O problema dos indicadores é que cada um deles funciona em seu próprio thread e, para funcionar, deve armazenar todos os dados necessários no próprio thread.
Os dados entre threads são copiados por meio de CopyBuffer(). Mas aqui está o problema: você pode obter dados de um thread, mas não pode transferi-los para lá. É por isso que você não pode criar indicadores mogostage nos quais várias instâncias de um indicador recebem os mesmos dados pré-processados. Mas nesse mesmo plano podem estar grandes oportunidades de otimização dos cálculos.
Acredito que se o MQ resolver esse problema, o trabalho com indicadores se tornará mais conveniente e flexível. Agora, os dados só podem ser passados como parâmetros externos e somente no início do thread.
- 2010.01.12
- MetaQuotes Software Corp.
- www.mql5.com
Muito útil
Então, se eu entendi corretamente o fluxo da ideia principal, surge uma pergunta:
Por que todos os indicadores padrão encontrados na instalação do MT5 não são projetados como "classe"?
Então, por que o mestre assistente não se importa com essa ideia?
sem limitar o número máximo de barras em Ferramentas> opções, uma maneira rápida que uso para reduzir o espaço do buffer é
int maxbars =100;// últimas barras limit = rates_total-rates_total+maxbars;
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
Novo artigo Diminuindo o Consumo de Memória pelos Indicadores Auxiliares foi publicado:
Se um indicador usa valores de muitos outros indicadores para seus cálculos, ele consome muita memória. O artigo descreve diversos métodos para diminuir o consumo de memória quando estiver usando indicadores auxiliares. A memória salva permite o aumento de pares de moedas, indicadores e estratégias usados simultaneamente no terminal cliente. Ele aumenta a confiabilidade do portfólio comercial. Esse cuidado simples sobre os recursos técnicos do seu computador pode se transformar em recursos monetários em seu depósito.
Autor: Andrew