|
Hola:
No creo que un Timer consuma muchos recursos, pero sí lo hace usar varios Timers. ¡Qué perogrullada!
Lo que sí es cierto es que un TTimer, al ser un componente no visual, crea una ventana virtual (un Handle de ventana) para que Windows le notifique los intervalos de tiempo. Esto es usar recursos tal vez inútiles del sistema, además de la lentitud que supone el uso de Handles de Windows. En cuanto a la eficiencia, como dice Jachguate, depende del código que se ejecute en el evento OnTimer del mismo.
También te advierto de que el TTimer es bastante impreciso, se suele entender que falla por debajo de intervalos de 50 milisegundos pero en mis pruebas falla mucho más. Es decir, que no es muy preciso, aunque depende de para qué, sí sirve (yo diría que a partir de intervalos de medio segundo = 500 milisecs).
Otra pega es que al ejecutarse dentro del TThread principal del programa, si hay un proceso que requiere mucho uso de procesador, el TTimer puede incluso no responder. Precisamente para evitar eso programé un Temporizador esta misma semana, y lo hice creando un TThread aparte, que mide el tiempo con GetTickCount o con QueryerformanceCounter, mediante un bucle que sólo hace eso, y el resultado es sorprendentemente preciso (deja al TTimer en pañales).
Pero para un uso general, si la precisión no es un tema crucial y si no vas a usar un montón de Timers, los recursos que consumen no son para preocuparse. Aunque requiera más programación, si hay varios procesos que deban usar un Timer, quizás sea mejor colocar uno sólo, con el intervalo menor requerido, y dentro del mismo controlar qué procesos se disparan o no.
¿Te he liado? Lo siento.
¿Te ha servido? Me alegro.
Saludos
|