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
Deixou apenas a variante 0-INT_MAX em robôs de combate. Parou de notar os freios.
O que você então faz com essa história?
Claro que posso mudar a sub-conta todos os meses para limitar o histórico do pedido a cerca de cem mil, mas essa não é a solução :)
O que você então faz com essa história?
Eu poderia mudar a sub-conta todos os meses para limitar o histórico do pedido a cem mil, mas essa não é a resposta :)
No momento, vejo que em 99% dos casos somente o HistorySelect(0, INT_MAX) deve ser utilizado. Tente não utilizar as outras opções.
Provavelmente o suficiente para não mover o início do cache, ou seja, sempre perguntar a partir da mesma data (e se é 0 é irrelevante).
Temos de verificar.
Provavelmente o suficiente para não mover o início do cache, ou seja, sempre perguntar a partir da mesma data (e se é 0 é irrelevante).
Precisa ser verificado.
Possivelmente. É difícil ser um testador por um longo período de tempo.
Resultado.
Em cada tique há um problema.
SZY instalado Win10, LatencyMon mostra que tudo está bem.
Por que você está fingindo ser tão ingênuo?
Você está tentando mostrar que não está bem matar o cache em primeiro lugar, é sua própria culpa. É por sua própria culpa que você está matando o cache em uma grande história. E é unicamente seu problema afinar propositadamente sua posição. Você pode encontrar muitas oportunidades para matar/eliminar um monte de caches no ambiente MQL5.
Não vamos ajudá-lo - em nenhuma linguagem de programação há um grande número de opções para atirar no pé e na cabeça.
Você seria tratado normalmente se você indicasse explicitamente "olhe - isto sou eu envenenando o cache de propósito e atirando em mim mesmo".Provavelmente o suficiente para não mover o início do cache, ou seja, sempre perguntar a partir da mesma data (e se é 0 é irrelevante).
Precisa ser verificado.
Isto é exatamente o que descrevi explicitamente.
Se você estiver recolhendo amostras por data, não tente fazer uma amostra diferente de cada pedido. E, até o momento, tente apresentá-la.
Controlamos especificamente o posicionamento e o reduzimos automaticamente para INT_MAX se este exceder ou igualar a data atual.
Você está tentando mostrar que matar o cache não é a norma, tanto antes como agora. É sua própria culpa por matar o cache em uma grande história. E é unicamente seu problema afinar especificamente a partir de uma posição. Você pode encontrar muitas oportunidades para matar/eliminar um monte de caches no ambiente MQL5.
Uma biblioteca utiliza o HistorySelect da TimeCurrent. A outra é de zero. Por que diabos eu deveria entrar na coragem das bibliotecas para descobrir que elas não são compatíveis umas com as outras por desempenho?
Um exemplo sucinto é descobrir por que bibliotecas inofensivas podem interferir umas com as outras. Finalmente, engaje-se em seu pensamento crítico.
Uma biblioteca utiliza o HistorySelect da TimeCurrent. A outra é de zero. Por que diabos é preciso entrar na coragem das bibliotecas para descobrir que elas não são compatíveis umas com as outras para o desempenho?
Um exemplo sucinto é descobrir por que bibliotecas inofensivas podem interferir umas com as outras. Enfim, ligue seu pensamento crítico.
É tão fodido que é seu problema pessoal que você usa bibliotecas e desliga sua cabeça.
É seu próprio problema usar bibliotecas e desligar a cabeça.
Por que você mesmo não vai e escreve tudo do zero em Asm? Acontece que não há problema quando cada uma das bibliotecas voa separadamente. Mas assim que você começa a usar os dois de uma vez, você começa a ficar lento.
Temos relatado com sucesso bugs à Microsoft, mas nunca os escrevemos ou acusamos de que existem cerca de N milhões de oportunidades para nos matarmos em seu API.
Especialmente enquanto se utiliza as bibliotecas de outras pessoas no processo.