Erros, bugs, perguntas - página 1625
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
mt4 compila em 888 msec.
o mesmo projecto compila 4103 ms em mt5
Não tenho dinheiro para MT5 - negoceio contas em cêntimos e o CD não tem pressa de as abrir por cinco cêntimos.
Há cerca de três meses atrás tentei levantar esta questão, mas não foi compreendida, aparentemente os meus argumentos não foram suficientemente convincentes. Por conseguinte, voltei à velha construção (1159), que compilou tudo quase instantaneamente (enquanto com novos compiladores o meu projecto compilou em 20 segundos).
E assim, há uma semana atrás, tenho tentado mudar para uma nova construção. Pensei "esquece cerca de 20 segundos, vou aguentar por causa de coisas novas". Claro que tive de afinar um pouco o código para cumprir novas condições, o que revelou vários bugs de novo compilador (sobre o qual relatei aqui).O resultado é que o meu projecto já está a ser compilado há 30 segundos! Não sei se tem a ver com a complicação do projecto ou com mais uma "complicação" do compilador, mas simplesmente já não se encaixa.
O projecto contém cerca de 700 Kb de código fonte, é um Expert Advisor contendo algumas dezenas de mqh. Tudo é OOP. As pessoas escreveram-me anteriormente que a desaceleração é provavelmente causada por grandes funções. Tive alguns deles. Bem, fragmentei-os em partes mais pequenas e não têm qualquer efeito.
O que é mais espantoso é que esta compilação superlongativa não tem qualquer utilidade. A velocidade do programa é a mesma que com o antigo compilador, medi-o especificamente. Isso pede apenas uma frase: "Para quê?".
Tenho a forte sensação de que existe um bug/mal funcionamento no compilador por causa do qual ele está a correr ociosamente através de um espaço vazio. De que outra forma posso explicar o facto de um script absolutamente vazio com apenas a função OpenStart() { } compila mais de 400 ms!É inimaginável que possa demorar tanto tempo a compilar/optimizar um guião vazio. Bem, acrescentando-lhe pequenas funções e classes, pode-se ver como o tempo de compilação cresce rapidamente.
Quero dizer desde já que o meu hardware está naturalmente longe de ser poderoso - Core i5U. Mas isto não impede o meu projecto de compilar em 1-2 segundos num compilador antigo. Respectivamente, o boneco é compilado lá num instante.
Vou também notar. O compilador carece completamente não só de cache de fragmentos compilados anteriormente, mas até de uma verificação trivial para se certificar de que o código fonte era idêntico. Ou seja, compila-se o projecto e depois clica-se novamente no botão "Compile" sem fazer quaisquer alterações e espera-se novamente pelos mesmos 30 segundos.
Gostaria de ouvir comentários dos programadores de MT e dos utilizadores do fórum, trabalhando com grandes projectos (sou apenas eu que tenho este problema?), quanto tempo demora a compilar, etc. Devemos dizer desde já que estamos a falar da compilação de um executável.
Os meus projectos têm mais de uma dúzia de ficheiros-fonte, como os seus, e todos no OOP, enquanto que eu não vou reivindicar cerca de 20 segundos, mas mais de 11 - 14 segundos que vejo constantemente. No entanto, está a ocorrer algum tipo de caching, uma vez que se não se mudar nada o tempo está a mudar em 1-2 segundos em qualquer direcção imprevisível. Não estou a comparar a construção dos projectos utilizando os compiladores antigos e novos porque os compiladores antigos construíram tudo muito mais depressa. Penso que os próprios criadores vêem este ponto e um dia irão corrigi-lo :) Não é por nada que lançam várias novas séries todos os meses - significa que vêem algo e o consertam.
Versão terminal e taxa de bits
v.1375, 64-bit
Descrição do problema.
Após a actualização para a última construção, os agentes congelam após passarem as primeiras passagens 1900-2100 durante a optimização. Tudo estava bem antes da actualização, todos os parâmetros e código EA são os mesmos.
Sequência de acções
Aoptimização começa. Abertura do corretor. Conta real. As ferramentas: Si Splice, Vtb Splice, Si 9.16, Vtb 9.16 (ainda não experimentei outros). Intervalo: mensal, minuto, 15 minutos. Preços de abertura ou OHLC.
Resultado.
Agentes locais e remotos depois de 2000 passagens realmente congelam, cargas de CPU, mudam em cerca de 0,01% por 10 minutos. 14 agentes.
Resultado esperado
Otimização de passagem como com a construção anterior.
Informação adicional
Sobre mim: programador experiente .net MQL5
No entanto, há algum caching em curso, porque se não se mudar nada, o tempo muda por 1-2 segundos em qualquer direcção imprevisível.
Em qualquer caso, 10-15% não são de todo os indicadores, para os quais o caching é feito.
Eu não compararia projectos de construção com compiladores antigos e novos porque os compiladores antigos construíam tudo muito mais depressa. Penso que os próprios criadores vêem este ponto e irão resolvê-lo em algum momento :) Não é à toa que são lançadas várias novas séries todos os meses, significa que eles vêem alguma coisa e corrigem-na.
São lançados novos betas porque as pessoas se queixam de vários bugs, mas se os bugs são um argumento sólido para os corrigir, todo o resto ... É preciso convencê-los durante muito tempo. Mesmo quando parece que trouxe claramente todos os argumentos, delineou claramente o quadro tão claro quanto possível, eles ainda resistem, por gancho ou por vigarista :) Aqui estou eu mesmo há 3 meses atrás tentei convencê-los, mas ninguém apoiou.
E vi que apenas algumas pessoas usam MQL para grandes projectos e provavelmente não se incomodam com os pequenos por causa de um par de segundos extra.
A propósito, que tipo de CPU tem?
... eles vão fazer o que puderem :)
Não procurei o suficiente. https://www.mql5.com/ru/forum/88768/page2#comment_2587760
Versão terminal e taxa de bits
v.1375, 64-bit
Descrição do problema.
Após a actualização para a última construção, os agentes congelam após passarem as primeiras passagens 1900-2100 durante a optimização. Tudo estava bem antes da actualização, todos os parâmetros e código EA são os mesmos.
Sequência de acções
Aoptimização começa. Abertura do corretor. Conta real. As ferramentas: Si Splice, Vtb Splice, Si 9.16, Vtb 9.16 (ainda não experimentei outros). Intervalo: mensal, minuto, 15 minutos. Preços de abertura ou OHLC.
Resultado.
Agentes locais e remotos depois de 2000 passagens realmente congelam, cargas de CPU, mudam em cerca de 0,01% por 10 minutos. 14 agentes.
Resultado esperado
Otimização de passagem como com a construção anterior.
Informação adicional
Sobre mim: programador experiente .net MQL5
Este comportamento ocorre com algum Conselheiro Especialista?
Seria bom ter os troncos. Por favor, envie um bilhete para o balcão de atendimento.
Os registos terminais são bons, mais interessantes são os registos do testador de estratégia e dos agentes de teste.
+ anexar ao seu bilhete pelo menos EX5 do seu Conselheiro Especialista (apagá-lo-emos após a investigação) + descrição dos parâmetros utilizados durante a optimização.