Erros, bugs, perguntas - página 2557
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
Sim, a queda é muito dura. É melhor não correr quaisquer riscos.
É tudo uma questão de memória, claro.
Se limpar a memória com a ajuda das suas mãos como estas:
então o acidente também não acontece. Pelo menos isso não me aconteceu.
Mas quando a TF está a ser mudada, as matrizes devem ser automaticamente limpas!
Não compreendo, porque devemos tratar da função Crash() se ela não o faz, porque lê apenas informação sobre indicadores.
Talvez, a execução desta função abrande OnDeinit quando se muda a TF, e por isso MT5 não tem tempo para limpar a memória.
Existem problemas com a função assíncrona OnDeinit durante muito tempo. Não é bom! O sistema não deve falhar devido à assíncronia.
1) é necessário truncar o esturjão com INT_MAX(2 bn) aqui:
também vamos resolver isso do nosso lado.
2) toda a memória tem de ser gerida de uma forma muito rigorosa, aqui não há GC
3) a reinicialização do indicador em mudança de prazo é quente sem reinicialização física de raiz, por isso é necessário libertar a memória por si próprio. especialmente recursos a nível global
4) utilizar o OOP, pelo menos dar-lhe-á a capacidade de descrever e controlar adequadamente os recursos
E aqui está uma captura de ecrã do sistema de carregamento quando o GP está quase em estado morto - porque não está a carregar?
Estou a falar de um processador FX-8350 e de uma placa gráfica Radeon HD 7950. Não tenho a sensação de que a placa gráfica seja carregada pelo MT5.
No entanto, é. A placa gráfica tem um grande impacto na velocidade de renderização, uma vez que é a utilizada na renderização.
A sua pergunta carece de informação sobre o ambiente em que a rolagem tem lugar.
Por exemplo:
Se a situação for estável, todos os dados são calculados e não há pedidos induzidos, então a placa de vídeo e a CPU são responsáveis pela carga.
Uma vez que afirmou claramente "saltar até 100% sobre UM núcleo, não todos os núcleos", esta é uma situação perfeitamente normal. O computador faz o seu trabalho - carrega o núcleo seleccionado e, ao fazê-lo, tem uma utilização de CPU = 12,5% de todos os 8 núcleos, não 100%.
1) é necessário truncar o esturjão aqui com INT_MAX(2 bln):
Também vamos corrigir isto.
2) Toda a memória deve ser gerida de uma forma muito rigorosa, não há aqui GC.
3) a reinicialização do indicador em mudança de prazo é quente sem reinicialização física de raiz, por isso é necessário libertar a memória por si próprio. especialmente recursos a nível global
4) utilizar o OOP, pelo menos dar-lhe-á a capacidade de descrever e controlar adequadamente os recursos
Para continuar o mesmo tópico, por favor veja este post - não está claro de onde vêm estes carrapatos quando a bolsa é fechada - devo contactar o corretor ou a bolsa?
Fórum sobre comércio, sistemas comerciais automatizados e teste de estratégias comerciais
MQL5 Calendários próprios
Aleksey Vyazmikin, 2019.09.07 09:50
Não sei, não sei o que fazer com eles, mas não sei se estão certos antes da abertura do mercado (o mercado abre às 10 da manhã)... E durante a limpeza.
E aqui está uma captura de ecrã da carga do sistema quando se desloca - o GP está quase num estado morto - porque é que não está a ser carregado?
Portanto, nada de grave lhe está a ser transmitido desta vez.
E aqui está o meu teste, num ecrã completamente em branco com rolagem activa: pode ver claramente o pico de carga, é a monitorização interna do Windows 10
No entanto, tem. A placa gráfica tem uma forte influência na velocidade de renderização, uma vez que é a utilizada na renderização.
A sua pergunta carece de informação sobre o ambiente em que a rolagem tem lugar.
Por exemplo:
Se a situação for estável, todos os dados são calculados e não há pedidos induzidos, então a placa de vídeo e a CPU são responsáveis pela carga.
Uma vez que afirmou claramente "saltar até 100% sobre UM núcleo, não todos os núcleos", esta é uma situação perfeitamente normal. O computador faz o seu trabalho - carrega o núcleo seleccionado e, ao fazê-lo, tem uma utilização de CPU = 12,5% de todos os 8 núcleos, não 100%.
Dou informações sobre o ambiente:
- Existem 16 indicadores, a renderização não é complicada, sem kanvas, barras de ferramentas, e outros folhos - paus/listras - anexo uma imagem de ecrã.
- Não há programas no gráfico, abro uma janela depois do optimizador, é como um exemplo - os gráficos de trabalho também são lentos, mas menos (há menos indicadores).
- Não, os eventos não são processados.
- O modo de visualização de barras ilimitadas é seleccionado, ou seja, a paginação é uma espécie de exclusão.
- Não há objectos gráficos, ou melhor, removi todas as setas e traços. Resta uma etiqueta - é do indicador. Hoje tenho um dia de folga e não deve interferir com ele.
Afixei uma imagem acima mostrando que a placa gráfica não está engatada, existe alguma forma de verificar se está engatada ou é normal que a carga esteja perto de zero e o núcleo esteja carregado?
Capturas de ecrã da plataforma MetaTrader
Si Splice, M1, 2019.09.07
JSC ''Otkritie Broker''', MetaTrader 5, Real
Portanto, nada de grave lhe está a ser transmitido desta vez.
E aqui está o meu teste, num ecrã completamente em branco, enquanto se desloca activamente: pode ver claramente o pico de carga, isto é monitorização padrão do Windows 10
Então talvez devesse, mas não é - como sabe?
Parece que já expliquei tudo com suficiente detalhe e de muitas maneiras diferentes.
O computador faz o seu trabalho. Todos os recursos de trabalho custam recursos e vê-se o consumo desses recursos.
O que o leva a pensar que na sua opinião os recursos não devem ser consumidos - não compreendo.
Não sei exactamente quais são as características da GPU que o MSI Afterburner considera. Há muitas características por aí e não tenho a certeza de qual é a carga total da GPU, em vez de um ponto em particular.
A minha prova: pego nela e apenas percorro a janela do navegador:
A situação é exactamente a mesma ao percorrer um gráfico no MetaTrader 5:
A utilização da placa gráfica pelo terminal é comprovada.
Considerando o facto de já ter passado 20 anos em projectos de terminais comerciais e a sua optimização, é estranho não confiar nas minhas palavras.
Então talvez devesse, mas não é - como sabe?
Parece que já expliquei tudo com suficiente detalhe e de muitas maneiras diferentes.
O computador faz o seu trabalho. Todos os recursos de trabalho custam recursos e vê-se o consumo desses recursos.
O que o leva a pensar que na sua opinião os recursos não devem ser consumidos - não compreendo.
Não sei exactamente qual é a especificação da GPU julgada pelo MSI Afterburner. Há muitas características por aí e não tenho a certeza de qual é a carga total na GPU, em vez de algum ponto em particular.
A minha prova: pego nela e apenas percorro a janela do navegador:
A situação é exactamente a mesma ao percorrer um gráfico no MetaTrader 5:
A utilização da carta pelo terminal está provada.
Considerando o facto de já ter passado 20 anos em projectos de terminais comerciais e a sua optimização, é estranho não confiar nas minhas palavras.
Não se trata de confiar em si! Estou apenas a assumir que há um problema com os condutores ou algo parecido, embora corram todo o tipo de jogos 3D.
O navegador carrega a placa de vídeo, bem, não todas as páginas, mas com videoclipes e algo semelhante - verifiquei.
Também a verifiquei. Depois atirei todos os indicadores construídos em MT5 no gráfico de 40 Índices e tudo está a rolar muito rapidamente, a carga central é de 20%-25%.
Então o problema está em algum indicador que eu tenho? Não compreendo, mas já está calculado. Durante muitos anos, tenho vindo a pedir a algum gestor que implemente, o que o utilizador poderia ver qual o programa/indicador/script no gráfico, quanto tempo de CPU seria muito conveniente.