Tiki em tempo real - página 16
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
Colegas, tenham em mente que a impressão sai de forma assíncrona com uma fila de saída limitada. Se você tiver um número rápido/grande deles, você pode pular as impressões por completo.
Se o buffer transbordar, isso é possível, mas somente os desenvolvedores lhe dirão isso. Se eles tiverem descarga() após cada impressão e um tampão de tamanho suficiente, é improvável que isso aconteça.
Se o buffer transbordar, isso é possível, mas somente os desenvolvedores lhe dirão isso. Se eles tiverem descarga() após cada impressão e o buffer for suficientemente grande, é improvável que seja.
Os desenvolvedores já lhe disseram - você não tem escutado atentamente))
A descarga não tem absolutamente nada a ver com isso. É utilizado em operações de arquivo.
Os desenvolvedores já disseram - você não tem escutado atentamente))
Flash não tem nada a ver com isso - de forma alguma. É utilizado para operações de arquivo.
Não creio que houvesse desenvolvedores nesta linha. Talvez em outro lugar eles tenham dito que podem pular as impressões, mas maldição :-) Eu não monitoro tudo o que eles escrevem neste fórum.
Sim, e o exemplo que estamos analisando no qual a impressão não é ignorada, mas tem apenas uma diferença de 4 segundos. E é claro que o tique está desajustado que veio no OnTick e no OnBook, e o desajustado dá a impressão de que no OnBook ele veio mais tarde em 4 segundos.
p.s.
Flush() é de nível baixo e alto e pode ser ajustado imediatamente após qualquer saída para o disco - se for necessário reinicializar. E não tem que ser para operações de baixo nível de escrita.
Se houver alguma coisa para enxaguar, ela será enxaguada para o disco a partir dos amortecedores. Depois de enxaguada, ela será enxaguada para o disco exatamente quando não for dispendioso fazê-lo.A propósito, acho que os desenvolvedores cuspem na perda de impressões em favor do desempenho.
A propósito, acho que os desenvolvedores cuspem na perda de impressões em favor do desempenho.
A perda de impressões, indica que o desenvolvedor não implementou a fila.
Se isto é bom ou ruim é discutível.
A perda de impressões, indica que o desenvolvedor não implementou a fila.
Se isto é bom ou ruim é discutível.
Eu não sei, eles saberão.
Seria bom desabilitar o raio do registro no testador em favor da velocidade, por exemplo.
A perda das impressões, sugere que o desenvolvedor não implementou a fila.
Se isto é bom ou ruim é discutível.
Isto é somente quando a saída para a tela. Todas estas impressões são salvas no arquivo sem nenhuma perda.
Consegui, misturei a impressão com a chegada do carrapato.
Realmente, a impressão fica muito atrasada.Acontece então que a função de impressão é a culpada.
E talvez, para testes, seja melhor emitir o resultado para um arquivo.
Aqui está um exemplo simples para verificar isto: imprima um laço decente,
e você pode ver imediatamente a velocidade de renderização da impressão e o tempo das impressões será normal.
Isto é apenas quando exibido na tela. Todas estas impressões são salvas no arquivo sem nenhuma perda.
Sim? Bem, então tudo bem.
Quer dizer, quando você joga no testador, às vezes você não precisa das impressões no arquivo ou na tela, mas você precisa da velocidade.