Duda sobre la cantidad de timers que puede soportar una aplicación
 

Hola a todos...
Tengo una duda sobre el número de timers que se puede usar en una aplicación cualesquiera. Esto me surge ante la necesidad de tener que usar un timer por cada elemento que quiera dar de alta en mi aplicación ya que cada uno tiene que poderse actualizar según el tiempo que se le configure independientemente del resto.
¿Alguien sabe si el número de timers puede ser muy grande?
Muchas gracias!!!:)

Hola!

Yo he usado hasta 15 timers en una aplicacion pero nunca de manera simultanea. Tal vez uno o dos simultaneos pero no mas, por otro lado recuerda que si tu aplicacion tiene necesidad de ser precisa en el tiempo los timers no tienen prioridad contra el resto de eventos del sistema por lo que deberas de adaptar algun componente de terceros.

Hola FGarcia! Gracias por tu respuesta... Necesito una cantidad mayor de timers (sobre los 80) pero lo normal es que no estén simultáneamente en uso, aunque en un caso muy extremo y extraño si pudiesen estar activos. Por otra parte no necesito una exactitud muy eleveda. Estamos hablando del orden de minutos con lo que no me importa un segundo más o menos (q no creo q sea tanta la desviación).

Gracias!!!

En la página de Ians Marteens tienes una entrada "midiendo el tiempo con precisión" que va sobrado para tí.

En lugar de tener 80 timers, deberías seguir la filosofía de Ians:
- "iniciar un timer" es simplemente coger en ese momento la cantidad de tiempo que lleva encendido el ordenador.
- "Parar un timer" es volver a coger ese número y restarlo al anterior. La diferencia es el tiempo que ha tardado una tarea.

Como ves no es exactamente un timer, pero lo importante de todo es que no tienes 80 timers en memoria, de hecho no tienes nada, sólo un par de llamadas a la API.

(aunque no necesites precisión, te recomiendo el QueryPerformanceCounter(X);)


Saludos

Hola Lepe...
Gracias por tu aportación, pero no entiendo muy bien que es lo que me quieres decir...
Según entiendo lo que me planteas es algo así como tener un sólo timer con un periodo determinado (digamos un segundo) y que cada vez que entre en su evento compruebe si debe actualizar un elemento. Sabrá si debe actualizar ese elemento si coincide digamos su variable MomentoActualizacion con el valor devuelto por QueryPerformanceCounter.
¿Es más o menos eso lo que me has querido decir? Corrígeme si me equivoco please... Salu2...

Sí, básicamente es eso.

Podrías utilizar un registro (o un objeto) por cada elemento que quieres dar de alta en tu aplicación, por ejemplo:

Código Delphi [-]
Type TElemento = record
   intervalo:Extended ; // el tiempo de tiempo que el usuario pone para actualizarse 
   inicio,  // cuando empezó a monitorizarse
   Fin :TDateTime ; // inicio + intervalo
   enMarcha:Boolean; // para saber si este crono está funcionando o no.
end;

elementos = array [0..79] of TElemento

Pero al hablar de "timers" y precisión me he ido por los cerros de úbeda.

Es más fácil poner un solo timer de 1 minuto. Cuando quieras dar de alta un elemento:
- asignas enMarcha a true para ese elemento.
- inicio := now; // una llamada a la fecha y hora actual del sistema
- Fin := inicio + intervalo; (intervalo expresados en días, por eso es un real, 1 segundo vendría a ser : 1 / (24 * 60 * 60))

En el evento OnTimer, captas la hora actual del sistema y la comparas con todo el array, así compruebas si tienes que actualizarlo o no.

Código Delphi [-]
actual := now;
for i:= 0 to 79 do
  if elementos[i].enMarcha then
    if elementos[i].Fin < actual then
    // hay que actualizar

Saludos.

Otra pregunta ya por curiosidad...
¿Qué es lo que ocurriría si se utilizase un número muy elevado de timers? ¿Simplemente la aplicación no podría crearlos o es que los timers puede que no tuviesen precisión?

¿Alguien lo sabe?

Gracias!!!

Interesante pregunta.

Además del obvio aumento de consumo de memoria y recursos (80 timers son 80 handles de memoria más), quizás "empezaran" a no ser precisos. Ten en cuenta que la aplicación sólo puede ejecutar una sola cosa al tiempo, si está procesando un evento de timer y llega otro, simplemente se añade a la cola de mensajes de la aplicación, para ir ejecutándolos en el orden de llegada. El último evento que llega, puede demorarse desde que se lanzó hasta que se ejecuta su código del evento OnTimer.

Incluso producir efectos indeseados en la interfaz, por ejemplo, al ejecutarse muchos eventos de timers no se repinta la pantalla (recordemos que los eventos de repintados en windows tienen poca prioridad), y se verían textos no actualizados aún cuando en el timer se haya ordenado cambiar un caption de un label... o cosas por el estilo.

Por otra parte está la lógica del programa, es mucho más fácil hacer una modificación (o depurar) si todo está centralizado, en lugar de tener 80 timers que administrar. Mentalmente no puedes saber cuando se ejecutarían esos timers, al estar centralizado puedes hacer una resta de fechas o usar SecondsBetween entre un timer y la hora actual para saber "cuanto tiempo le falta a ese timer para que se ejecute su código"

Algunas veces es necesario descentralizar para ordenar el código, en este caso, creo que añade ventajas el tenerlo centralizado.

Saludos curiosón ;)

Saludos.

A mí entender, puedes ejecutar tanto timers como memoria tengas disponible si utilizas el recurso de los Thread (Hilos); lo que sí veo un tanto incomodo es la administración de los mismos al ser un elevado número de procesos.

Hola a todos de nuevo... Leyendo la respuesta de Rolphy Reyes me asalta la siguiente duda: ¿un timer no es un thread?. Es decir, a mi modo de entender un timer, yo pensaba que no era más que un thread en paralelo que cuando le toca realizar una tarea la realiza sin más. ¿Qué diferencias habría entre tener varios timers en una aplicación y varios hilos con un timer?
Gracias por vuestras respuestas...
PD: hay q ver todo lo que estoy aprendiendo :D!!! (y todo lo que me queda por aprender :()

Saludos!!!:rolleyes:

La diferencia básica y principal es que cuando ejecutas un Timer desde la aplicación sin Thread (Hilos) se ejecuta en modo Sincrónico y con hilos es Asincrónico.

No.

Un TTimer de delphi sólamente engloba varias llamadas a la API de windows, (las más relevantes: SetTimer y KillTimer) además de ponerte el componente en la paleta de delphi para más comodidad.

Como esas rutinas pertenecen a la API, es difícil saber cómo están implementadas internamente. Hace mucho leí que un ordenador incluía 4 cronómetros hardware y que dichas APIs lo manejaban, (no tengo referencias para corroborar eso).

Saludos

Supongamos entonces que quiero implementar un reloj. Lógicamente este deberá cambiar cada segundo. ¿Con qué sería mejor hacer esto con un timer o con un thread? ¿Qué ventajas/inconvenientes podría tener cada uno?

De nuevo mil gracias por vuestras respuestas y vuestra paciencia... :rolleyes:

No te compliques la vida, un timer y marchando.

Pues usando el reloj del sistema que para eso esta :) . No intentes contar tu los segundos, por ejemplo incrementando una variable en el evento del timer porque por muy preciso que sea siempre tendras un pequeño error y con el tiempo (despues de un par de horas) "tu reloj" terminara atrasando o adelantando. Lo mejor es que utilices el timer para mostrar el valor de hora del sistema en, por ejemplo, un label.

Código Delphi [-]
label1.caption:= TimeToStr(Now);

¿Y si quieres hacer un cronometro? Pues te digo lo mismo :) Simplemente tienes que guardar el valor inicial. Por ejemplo:

Código Delphi [-]
// Cuando comiences la cuenta
Marca:= Now;
 
 
// Para mostrar el tiempo transcurrido
label1.caption:= TimeToStr(Now-Marca);

¿¿80 timers??... pues el problema que salta a la vista es el consumo de recursos, y muy posiblemente la sincronización de componentes y variables....

¿¿¿Por que no pensar en un solo Timer, que controle la actaulización de los 80 componentes???.

Tu dices que cada Componente se actualiza con diferente intervalo de tiempo, pues no importa, debes idear una estructura en la que lleves la hora de inicio y el intervalo por cada componente. El timer se podría ejecutar cada segundo y evaluar en una sola función todos los componentes....

Saludos,

¿Y no es acaso lo que recomendó Lepe unos post antes?:confused:

Saludos,

Ahora lanzo otra pregunta vista las respuestas. ¿Qué sería más conveniente usar entonces un timer y comprobar todos los elementos o usar el recurso de los hilos como propone DolphyReyes?

Si los procesos a ejecutar por cada elemento a comprobar son bastantes cortos, simples y no ocupan demasiados recursos yo diría que el uso del timer es una opción buena. Pero es necesario que se le dé el tiempo necesario al timer para que pueda terminar con su rutina.

Por ello cuanto más simples y elementales sean los procesos que intervienen, mejor para el timer. Tener una "ventana temporal" de un minuto es más que suficiente (creería) para que se ejecute todo.

Por el otro lado, el uso de los timers puede mejorar la perfomance de la aplicación; pero a mi modo de ver tener 80 hilos es algo bastante engorroso. Si 15 ya son un lío, 80 (si cada uno hace un solo proceso) son un lio descomunal.

Saludos,

Yo no se, pero por lo menos a mi me es muy dificil poder recomendar algo, sin tener una minima idea de que es lo que estarian haciendo esos timer.;)


Un Saludo.