Timer
 

Me entere por ahi que el Timer de Delphi consume muchos recursos y a la larga termina poniendo lentos todos los procesos.
Esto es real, y si es asi, Existe algun componente que solucione este problema ?

Un "timer de delphi" no es mas que una interfaz a un timer del sistema operativo... y uno solo, en mi experiencia no pone lento nada... depende de lo que hagas en el evento OnTimer, de la frecuencia con la que se dispara, de la prioridad del proceso o thread donde se ejecuta, etc, etc.

Hasta luego.

;)

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

Hola Andres.

Ciertamente los timers en windows son bastante imprecisos. La documentación y sobre todo la experiencia lo ratifican. Por ello no están recomendados para realizar procesos críticos. De hecho, si el timer expira varias veces, y por alguna razón el sistema operativo no puede notificarlo a tiempo, tu programa recibirá una única notificación.

Al final será decisión del programador que estrategia usar para resolver sus necesidades. Los timers son bastante buenos, con sus limitantes, pros, y contras. El hacer un timer propio, utilizando un mecanismo similar al que vos comentas en la creación de tu componente, puede ser arriesgado, y aunque no consuma un valioso Handle del sistema, puede elevar el consumo del procesador debido al bucle donde está comparando el tiempo (aunque me imagino que los timers del sistema deben hacer algo similar...)

Hay ciertos aspectos, tales como la carga del procesador, la prioridad que el sistema le de al proceso que ejecuta el timer, etc, que pueden afectar la forma en que se desempeña tu código.

Como dije al principio, depende de las necesidades y características de los programas y equipos donde corran cual será la decisión mas correcta.

Hasta luego.

;)

Gracias por las respuestas!!! Igual seguiremos escuchando opiniones.

Hola:

Coincido con tu apreciación, Jachguate. El hacer un "Timer propio", empleando un bucle en un Thread aparte, ciertamente consume mucho procesador, pero se hacía necesario para la aplicación en cuestión, donde se está a la espera de varias señales externas que se suceden con determinadas frecuencias (inferiores todas a 100 milsecs). Habíamos comprobado que el Timer se detenía si, por ejemplo, el usuario hacía un scroll prolongado sobre un DBGrid o cosas similares, con lo cual se perdía el rastro de ciertas señales, cosa que no podíamos permitirnos.

Como dices, depende de lo crítico que sea el proceso, tampoco soy partidario de usar ese tipo de solución salvo en casos muy concretos. De hecho, la prioridad del Thread debía ser tpNormal, más de ahí paraliza el resto de la aplicación, por lo que hay que ir con cuidado con este tipo de experimentos.

Saludos