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

[[gatosoft]]

¿¿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,

[[Delphius]]

Empezado por gatosoft

¿¿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?

Saludos,

[vejerf]

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?

[[Delphius]]

Empezado por vejerf

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,

[JoseFco]

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.

[vejerf]

Empezado por Delphius

Tener una "ventana temporal" de un minuto es más que suficiente (creería) para que se ejecute todo.

¿A qué te refieres con ventana temporal Delphius? ¿Al intervalo del timer o al tiempo que podrían tardar los procesos dentro del timer?

[[Delphius]]

Empezado por vejerf

¿A qué te refieres con ventana temporal Delphius? ¿Al intervalo del timer o al tiempo que podrían tardar los procesos dentro del timer?

Me refiero al intervalo del timer.
Una vez que el Timer se dispara cuenta con un minuto para realizar lo necesario, antes de que nuevamente se dispare.
Cuanto más simples sean los procesos mejor, ese tiempo que se dispone en el timer puede llegar a satisfacer con tranquilidad a los procesos.

Todo dependerá de que hará cada cosa y el tiempo que se necesite o demande para llevarlo a cabo. Lo importante es saber determinar un valor de intervalo que no sea ni largo ni corto. Tal vez llevar una especie de auditoria y monitoreo de cada proceso involucrado puede servirte para determinar el marco temporal adecuado.

Quizá hasta es viable establecer un modelo dinámico. Es decir, que el mismo sistema sea capaz de autoregular el intervalo del timer. Por darte una idea: se puede calcular un promedio o mediana (en algunos casos es más precisa la mediana) y en bases a nuevas mediciones recalcular el nuevo tiempo de espera. De este modo se puede llegar a conseguir mejores resultados ya que no se "desprecia" tanto uso del CPU en estar constantemente evaluando procesos que tal vez no tienen una gran prioridad o que no tienen una frecuencia tan elevada.
Un esquema basado en prioridades es útil en algunos casos.

En fin, es una alternativa o una mirada diferente a la que te han estado ofreciendo. A lo que quiero llegar es que deberías preguntarte: ¿Es realmente necesario un marco de un minuto? ¿Todas las actividades tienen la misma prioridad? ¿Cuáles son las probabilidades de que todos los procesos deban realizarse en un mismo instante?

Saludos,

[vejerf]

Hola de nuevo,
Después de un tiempo meditando y viendo que podía ser mejor me decanté por la propuesta de Lepe y usé un registro por cada elemento para ver en qué momento debía de actualizarse.
No conforme del todo con el resultado obtenido me planteé el uso de threads, uno por cada elemento. Ahora mismo estoy en ello aunque tengo un par de dudas:
- Primero: No sé que pensáis qué es más conveniente si un timer y comprobar cada cierto tiempo si un elemento ha de actualizarse o, como estoy haciendo ahora, un thread por cada elemento y cuando le llegue su momento se actualizará.
- Segundo: Esta pregunta es por desconocimiento del funcionamiento de un thread. Un thread cuando finaliza su método execute hay que liberarlo? Cuando se libera deja la variable a la que lo tenía asignado con el valor nil? Teniendo en cuenta que cuando se está ejecutando el hilo y llega una actualización tengo que incrementar el periodo de finalizacion en intervalo, se puede usar la condición siguiente siendo fin una variable publica del hilo?:

Código Delphi [-]
if Elemento.hilo = nil then
    // Crear hilo
else
   Elemento.hilo.fin := Now+Intervalo;

Gracias!!!