.net - timers - visual studio c# timer
System.Windows.Forms.Timer rendimiento (3)
¿Los temporizadores disparan en diferentes momentos para cada control? ¿Cada uno de ellos necesita un temporizador por separado?
Recuerda que puedes conectar varios manejadores de eventos a un solo evento, así que si estás usando los temporizadores para hacer animaciones simples, quizás puedas hacer eso con un temporizador disparando eventos para muchos controles ...
Tenemos una aplicación que contiene muchos controles de usuario que se actualizan frecuentemente en base a un System.Windows.Forms.Timer. ¿Puedo agregar una instancia de Timer de forma segura para cada control? ¿O debería tener un Singleton Timer que se ejecute todo el tiempo que va a ser utilizado por todas las instancias? ¿Qué está pasando realmente debajo del capó? ¿Habrá un hilo adicional (para contar) para cada temporizador?
No hay hilo adicional Hay muchos mensajes WM_TIMER en la cola de mensajes de su secuencia. Por lo tanto, estos temporizadores no ejecutarán su código en paralelo, incluso si sus intervalos de tiempo se superponen.
Creo que no estaría de más tener un temporizador separado para cada control. Al menos definitivamente no tendrá ninguna diferencia de rendimiento medible con respecto al uso de un solo temporizador. El código será más legible sin embargo. ;)
Por cierto, con el movimiento masivo de hoy a múltiples núcleos de CPU, considere si este quizás no es un lugar donde pueda beneficiarse de él.
System.Windows.Forms.Timer se implementa a través de buenos User32 Timers . Como tal, no usan ni requieren un hilo separado para la operación. Dicho esto, son un recurso limitado, ya que no se puede tener un número infinito de ellos.
Cuando dices que tienes muchos controles de usuario usando temporizadores, ¿a qué te refieres con "mucho"? 10? 10000?
Cuando dices que actualizan con frecuencia, ¿a qué te refieres realmente? ¿Cada minuto? Cada 100 milisegundos? ¿Tan rápido como puedan disparar sus temporizadores?
Prueba de estrés tu aplicación Vea cuántos controles puede tener activos antes de que empiecen a fallar o que sean tan lentos que no se puedan usar. Lo más probable es que llegue al punto donde la sobrecarga del procesamiento interno de los mensajes WM_TIMER mata el rendimiento mucho antes de que se quede sin recursos.