Es eficiente una función de espera?

[Danielo515]

Bueno, es una dudilla, estúpida que tengo. ¿Resulta eficiente una función cuya única función (valga la redundancia) es que le pasas un número dado de segundos y ella los cuenta y te hace esperar mientras tanto? Lo digo porque como cuando un proceso llama a una función se queda esperando hasta que esta acaba, me pareció excelente la idea, y queda mucho más elegante poner esperar(2), que andar reiniciando y comprobando un timer en cada proceso. No se, me parece mejor así.

Y ya que estamos, el límite de los timers cual es? supongo que el límite de int, si no recuerdo mal, esto en segundos ¿Cuanto puede ser? para medir minutos (con que mida uno sobra) es más que suficiente, pero bueno, ya que habro un hilo aprobecho.


Nota: conozco la función time, de hecho la uso mucho.

[Noivern]

siempre puedes hacer un frame(100*FPS*segundos_deseados)
Tengo la impresión que una función es un poco más lenta, pero es debido a que no tengo claro si al utilizar locales en la función hacen referencia al proceso que la invocó o son propias de la función. Si es el último caso, me atrevería decir que es menos eficiente usar una función.

[Windgate]

Las locales son propias de la función. Actualmente la única diferencia entre función y proceso es que la función detiene la ejecución de quien la invoca, y que en lugar de retornar un ID de proceso puede retornar el valor que tú desees con RETURN.

No veo ineficiente lo de usar una función de espera, aunque debes de tener en cuenta que durante el tiempo que espere el proceso quedará "congelado" xD

[Noivern]

Si se utiliza mucho la función se crean y eliminan muchas veces las variables locales, y por mínimo que sea, igual relentiza algo la ejecución.

[Danielo515]

Variables locales tiene una, la que usa para saber cuanto tiempo ha pasado.Nada más.

[Windgate]

Variables locales si tienes en cuenta las que vienen de serie: x,y,z,graph,angle,flags,file,father...

Hay un huevo.

Una solución es crear una "cerradura" mediante un INCLUDE cerradura.prg; donde el código de cerradura.prg sería

Code Select Expand

LOOP
   contador++;
   IF ( contador == limite )
      BREAK;
   END
END

Ten en cuenta que INCLUDE no requiere que sea un módulo cerrado, se puede hacer un include en cualquier punto del programa, y simplemente inserta el código que haya.

Con esa solución no creas nuevo proceso ni función ni se generan ni liberan locales de ningún tipo.

[Danielo515]

siempre puedes hacer un frame(100*FPS*segundos_deseados)
Tengo la impresión que una función es un poco más lenta, pero es debido a que no tengo claro si al utilizar locales en la función hacen referencia al proceso que la invocó o son propias de la función. Si es el último caso, me atrevería decir que es menos eficiente usar una función.

¿Pero eso no ralentizaría la ejecución de los demás procesos? ¿o solo del proceso en cuestión? La idea me gusta por un motivo, puedo definir una constante de tiempo de espera y así no tengo que ir cambiando los tiempos de espera proceso a proceso.
Probaré

[Danielo515]

Variables locales si tienes en cuenta las que vienen de serie: x,y,z,graph,angle,flags,file,father...

Hay un huevo.

Una solución es crear una "cerradura" mediante un INCLUDE cerradura.prg; donde el código de cerradura.prg sería

Code Select Expand

LOOP
   contador++;
   IF ( contador == limite )
      BREAK;
   END
END

Ten en cuenta que INCLUDE no requiere que sea un módulo cerrado, se puede hacer un include en cualquier punto del programa, y simplemente inserta el código que haya.

Con esa solución no creas nuevo proceso ni función ni se generan ni liberan locales de ningún tipo.

Uhm, es buena idea, aunque básicamente es una MACRO  ¿no?

[Windgate]

Algo así... INCLUDE es una mera expansión de código, no es una inclusión de módulo aunque también sirve como tal.

Podrías probar lanzando 16K procesos con función de espera y con el INCLUDE, y medir CPU y RAM usada en cada caso, se notará la mejora forzosamente.

[Noivern]

siempre puedes hacer un frame(100*FPS*segundos_deseados)
Tengo la impresión que una función es un poco más lenta, pero es debido a que no tengo claro si al utilizar locales en la función hacen referencia al proceso que la invocó o son propias de la función. Si es el último caso, me atrevería decir que es menos eficiente usar una función.

¿Pero eso no ralentizaría la ejecución de los demás procesos? ¿o solo del proceso en cuestión? La idea me gusta por un motivo, puedo definir una constante de tiempo de espera y así no tengo que ir cambiando los tiempos de espera proceso a proceso.
Probaré

Osea deja esperando al proceso que invoque al frame() y solo a ese. Ojo que los fps pueden variar segun la carga que se tenga al momento de utilizar esa función. Yo dejo en una constante (o bien una global) los fps que deseo que tenga el juego y al utilizar el frame() espera x segundos en función de los fps que pretendo que sean constantes. De esta manera, si por algún motivo los fps bajan, el proceso va a esperar más tiempo real, pero va esperar la misma cantidad de frames que si el juego fuese a la velocidad esperada. Espero no haber enredado más con la "explicación" xD

[Drumpi]

siempre puedes hacer un frame(100*FPS*segundos_deseados)
Tengo la impresión que una función es un poco más lenta, pero es debido a que no tengo claro si al utilizar locales en la función hacen referencia al proceso que la invocó o son propias de la función. Si es el último caso, me atrevería decir que es menos eficiente usar una función.

¿Pero eso no ralentizaría la ejecución de los demás procesos? ¿o solo del proceso en cuestión? La idea me gusta por un motivo, puedo definir una constante de tiempo de espera y así no tengo que ir cambiando los tiempos de espera proceso a proceso.
Probaré

Cada proceso es independiente de los demás, que un proceso haga varios frames en blanco no les afecta para nada.
Lo único que varía la velocidad de ejecución es SET_FPS... o que el rendimiento sea inferior a la potencia del sistema y se ralentiza.

Es típico pensar eso, acostumbrados a la programación secuencial y al uso de delay. Una función delay no tiene sentido en Bennu, porque se necesitaría que estuviese en todos y cada uno de los procesos... y aun así, SET_FPS  hace que el sistema se espere a que llegue el tiempo para llegar a los frames por segundos.