Tthread Vs. Application -> ProcessMessages();
 

Me gustaría que alguien me dijese ya que no puedo probarlo yo ya que no sé utilizar los hilos, si hay mucha diferencia de rendimiento entre una opción u la otra.

Mi programa necesita hacer una tarea cada segundo y he notado que el rendimiento de la aplicación ha bajado un montón. Yo utilizo Application->ProcessMessages(); para un bucle for el cual tiene que ir modificando el valor de unos 20 Edit y previamente leer estos valores de un archivo de texto...

Bueno, si alguien quiere hacer algún comentario al respecto...me interesa conocer más el tema.

:)

Hola.

Para que obtengas una buena y amplia información sobre el tema te recomiendo que leas unos artículos publicados en las revistas Síntesis nº 11, 12 y 13 del Grupo Albor.

La verdad es que no tiene mucho que ver lo uno con lo otro.
Application.ProcessMessages lo único que hace es que windows procese mensajes de los que hay en la cola de mensajes. Se suele utilizar por ejempo, cuando estamos dentro de un bucle, para que la aplicación no se quede "congelada" cuando estamos ejecutando un código continuamente.

Si utilizas threads, conseguirás que determinados procesos se ejecuten en un thread diferente al de la aplicación principal.
Puedes usar lo uno, lo otro, los dos o ninguno, ya que son cosas independientes.

Por lo que explicas, creo que esa tarea que haces cada segundo "tiene pinta" de que se debería ejecutar en un thread aparte.

Vamos a ver si no me lío al intentar explicarme :D

Una aplicación gráfica tiene lo que llamamos el bucle de mensajes, que se esta ejecutando siempre, en delphi se correspondería al método Application.Run. Este bucle esta procesando continuamente los mensajes, y cuando termina la aplicación se cierra.

Cuando al procesar uno de los mensajes (se pulsa un botón, un timer, etc ...) nos metemos en un bucle que va a tardar un poco en terminar, suele ser recomendable procesar los mensajes para que la aplicación no se congele. Pero tenemos dos inconvenientes, el primero es que los mensajes y se ejecutan dentro del nuevo bucle, es decir se para lo que se esta haciendo dentro del bucle para realizar otras tareas, por lo que si es un proceso critico no parece muy adecuado. El segundo es algo mas "conceptual", a mi no me parece adecuado que el bucle de mensajes, llame otro bucle, que a su vez procese los mensajes, no veo del todo bien esa "duplicidad".

Bueno, después de todo ese rollo :D , estoy de acuerdo con neftali en que tu programa tiene toda la pinta de necesitar threads. Así los eventos relacionados con los mensajes (botones, timers, etc ...) se ejecutaran por un lado, a su ritmo, y tu bucle se ejecutara por otro lado, sin interferencias, y sin tener que compartir su tiempo con nadie.

Me parece mas la comparacion entre el uso del TThread y del Application.OnIdle, quizas quisiste decir esto no lo se, para tener ma control el uso del TThread es recomendable,

Si no quieres liarte mucho con los detalles de usar el TThread existe un componente q te ayuda a usarlo sin escribir codigo, se llama TJvThread y esta en la libreria JVCL

Es verdad, es un rollo:D. No entendi la idea.

Saludos

Una "y" se le puede escapar a cualquiera ... :o

Si, pero fijate que pasé un tiempesillo en adivinarlo:).

Saludos

Ohhhh
 

Toda la vida usa Threads... tu aplicacion aparenta ser lenta porque un solo hilo procesa todo, los Mensajes (OnIdle, Timer, etc, etc....) si usas un Thread es independiente del proceso, si este hilo tiene un loop, eso a tu aplicacion no le afecta!

Saludos