Tiki en tiempo real - página 16
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Colegas, tened en cuenta que Print sale de forma asíncrona con una cola de salida limitada. Si tiene un número rápido o grande de ellos, puede omitir las impresiones por completo.
Si el buffer se desborda, es posible, pero sólo los desarrolladores te lo dirán. Si tienen flush() después de cada impresión y un buffer de tamaño suficiente, es poco probable.
Si el buffer se desborda, es posible, pero sólo los desarrolladores te lo dirán. Si tienen flush() después de cada impresión y el buffer es lo suficientemente grande, es poco probable.
Los desarrolladores ya te lo han dicho - no has escuchado con atención))
La descarga no tiene nada que ver con esto. Se utiliza en las operaciones de archivo.
Los desarrolladores ya han dicho - no has estado escuchando con atención))
El flash no tiene nada que ver, en absoluto. Se utiliza para las operaciones de archivo.
No creo que haya habido desarrolladores en este hilo. Puede que en otros sitios dijeran que pueden saltarse las impresiones, pero joder :-) no controlo todo lo que escriben en este foro.
Sí, y el ejemplo que estamos analizando en el que no se salta la impresión, sino que sólo tiene una diferencia de 4 segundos. Y claramente el tick es unset que llegó en OnTick y en OnBook, y el unset da la impresión de que en OnBook llegó más tarde por 4 segundos.
p.d.
Flush() es de bajo nivel y de alto nivel y puede establecerse inmediatamente después de cualquier salida al disco - si se necesita reiniciar. Y no tiene por qué ser para operaciones de escritura de bajo nivel.
Me refería a que si hay algo que tirar, se tirará a disco desde los buffers. Después de tirar, se tirará a disco exactamente cuando no sea costoso hacerlo.Por cierto, creo que los desarrolladores escupen la pérdida de impresiones en favor del rendimiento.
Por cierto, creo que los desarrolladores escupen la pérdida de impresiones en favor del rendimiento.
La pérdida de impresiones, indica que el desarrollador no implementó la cola.
Es discutible si esto es bueno o malo.
La pérdida de impresiones, indica que el desarrollador no implementó la cola.
Es discutible si esto es bueno o malo.
No sé, ellos lo sabrán.
Estaría bien desactivar el infierno del registro en el probador en favor de la velocidad, por ejemplo.
La pérdida de las huellas, sugiere que el desarrollador no ha implementado la cola.
Es discutible si esto es bueno o malo.
Esto es sólo cuando se muestra en la pantalla. Todas estas impresiones se guardan en el archivo sin ninguna pérdida.
Lo tengo, confundí la huella con la llegada de la garrapata.
Realmente, la impresión se retrasa mucho.Entonces resulta que la función de impresión es la culpable.
Y tal vez para las pruebas, es mejor dar salida al resultado en un archivo.
He aquí un ejemplo sencillo para comprobarlo: imprimir un bucle decente,
y se puede ver inmediatamente la velocidad de la representación de la impresión y el tiempo de las impresiones será normal.
Esto es sólo cuando se muestra en la pantalla. Todas estas impresiones se guardan en el archivo sin ninguna pérdida.
¿Sí? Bueno, entonces está bien.
Es decir, cuando juegas en el probador, a veces no necesitas las huellas en absoluto, ni en el archivo ni en la pantalla, pero sí necesitas la velocidad.