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
Sí, no vi que fuera un gráfico interno.
Pues a juzgar por el perfil, el origen de los frenos, al desplazar el gráfico, está en esta línea:
Perfilado con desplazamiento activo:
Perfilado con movimiento activo del ratón sin desplazamiento (sin el LKM pulsado):
ZS: Así que la fuente de los frenos no son los kanvas después de todo, sino los objetos.
Desgraciadamente, mi perfilado de este código da un resultado negativo. b2828.
Desgraciadamente, mi perfilado de este código da un resultado negativo. b2828.
Parece que aún no han terminado el perfilador. Yo también me quedaba en blanco a veces. Pero ahora funciona.
También funciona con éste.
Este es el enfoque equivocado. Sobre todo porque el probador visual tiene un modelo de renderizado diferido diferente, para no ralentizar completamente el proceso de pruebas.
Ya veo. Así que,además de medir en el probador, tendrás que medir en el gráfico.
Yo no he dicho eso.
Señalé los errores obvios y expliqué cómo funciona el sistema de renderización.
Pues entonces me he equivocado. Lo siento.
Parece que aún no han terminado el perfilador. Yo también me quedaba en blanco a veces. Pero ahora funciona.
este también funciona.
Yo también no tengo nada en el b2830.
con el modelo de eventos de Windows - incluso si se mueve el ratón rápidamente, la carga de la CPU comienza a aumentar, sin importar qué aplicación estaba en foco
SZY: Comprobado en el administrador de tareas en Win10... No muestra ningún aumento en la carga de la CPU por alguna razón, en Win7 exactamente la misma carga aumentaba si movía el ratón rápidamente - Dudo que Win10 haya cambiado drásticamente el modelo de eventos, lo más probable es que el administrador de tareas funcione de una manera diferente
Vin10. Este es el gráfico cuando muevo el ratón en la ventana de entrada de este mensaje de texto con el LKM pulsado
Aquí está sin el LKM
Vin10. Aquí está el gráfico cuando muevo el ratón en la ventana de entrada de este mensaje de texto con el LKM pulsado
Aquí está sin el LKM.
no es obvio
Aquí está el escritorio virtual con Win7 - si no muevo el ratón, se carga la CPU 3-4%
si el ratón se mueve rápido - 11-14% de carga
Me refiero a que la cola de mensajes en Win siempre necesita ser procesada, pero son ciclos de CPU extra - googlea "C++ windows window" - cualquier manual para escribir aplicaciones de windows en C++ usando WinAPI, lee allí sobre el manejador de mensajes
no es ilustrativo.
desde una máquina virtual en Win7 - si no mueve el ratón, 3-4% de carga en la CPU
si el ratón se mueve rápido - 11-14% de carga de la CPU
Me refiero a que la cola de mensajes en Win siempre tiene que ser procesada y toma ciclos de CPU extra - google "c++ windows window".
Para ponerlo en números más claramente, no estoy haciendo nada - 10-15 fluctúa, 17-30 cuando se mueve.
Pero si esto hace que OnTimer se ralentice 2 veces, no, por supuesto, a no ser que esté al 95-99% de carga.
Cualquier manual sobre la escritura de aplicaciones de ventanas de Windows en C++ utilizando WinAPI, leer allí sobre el controlador de mensajes
Pero si hace que OnTimer se ralentice dos veces, no, por supuesto, excepto para una carga del 95-99%.
el temporizador también es un evento WinAPI, pero dudo que todos los programas MQL se suscriban al temporizador del sistema - emula el entorno MQL(máquina virtual)
El manejador de mensajes toma parte de la CPU y así sucesivamente, sólo que no se utiliza cuando no hay cola. Para los procesos MT no debería haber un corte de tiempo de CPU en esta carga.
Siempre hay una cola en una ventana activa. Es una suposición común de cómo esta cola es distribuida por el terminal entre los gráficos y luego entre los programas MQL.
bueno, al final - para obtener un modo de monopolio y no para procesar los mensajes - no hay muchas opciones, la primera que viene - exclusiva aplicación de modo de pantalla completa, pero eso es otra historia, como si la "batalla por los recursos PC", entonces sólo necesita una API para ir a la bolsa y escribir su aplicación, y no registrar la ventana o no
Vale, no me interesa buscar picos de carga en la CPU - mientras estemos en Vin, puede pasar cualquier cosa, generalmente me parece bien
el temporizador también es un evento WinAPI, pero dudo que todos los programas MQL se suscriban al temporizador del sistema - emula el entorno MQL(máquina virtual)
no es un hecho. si recuerdas que hubo un error con el temporizador y el número de manejadores en el terminal, indirectamente sugiere que cada temporizador en MT bien puede ser un wineplay del sistema