La duda es, tengo el borrado de funciones arriba, pero al poner nil a select, SE SUPONE que ya la funcion no se cumple, y si pongo el dofile antes, es más de lo mismo, ya no limpia variablews... Entonces eso funciona bien o no...
Saludos y espero haberme expresado bien...
¡Iníciate en Linux fácilmente! Sólo entra aquíy comprueba que distribución se adapta mejor a tí.
Veo que tienes una variable "salir" que seguramente es booleana, y otras que serán enteros. Son tipos simples, o definidos, a esas no tienes que hacerles un nil, Si son globales, porque no tiene sentido eliminarla a no ser que acabes el programa (y se eliminarán sólas), y si son locales porque ya se destruyen al salir de la función.
La "problematicas" son las que tienen gran cantidad de bytes, como imágenes o tablas (arrays).
Es que bg, jugar, comoj, salir y opciones son variables de imágenes, y el programa no se acaba, si no que simplemente se cambia de script, y como no se vuelven a necesitar, se quitan.
Saludos
¡Iníciate en Linux fácilmente! Sólo entra aquíy comprueba que distribución se adapta mejor a tí.
jugar y salir es una variable que contiene una imagen??????
Deduzco que serán las opciones de un menú entonces.
Bueno, yo no lo vuelvo a repetir, que uno parece tonto siempre diciendo lo mismo. Os creáis una variable por opción en vez de tenerlo todo en un vector. Fijaros en el código de XYZ3D, más abajo, la forma elegante de limpiar un vector, eso da claridad de código, lo demás es programar mal.
Yo haría un tutorial sobre el tema, pero por motivos personales, no pienso hacer más tutos aquí. Si podéis echad un vistazo en google sobre trabajar con vectores, veréis como se os facilita la vida (y mucho).
Suerte cuando os salga un trabajo y tengáis que hacer una apliación con 50 opciones.
Aunque sea lo mismo que ha dicho ZYX3D, lo vuelvo a repetir porque tiene mucha razón, y me parece algu muy importante. Es mejor liberar los recursos por uno mismo que usar un recolector de basura. Y después de leerle como se hace en Lua, no es nada complicado, tan sólo poner la variable a un valor nil.
Los recolectores de basura tienen un problema y es que bajan el rendimiento, se pueden usar de forma puntual, pero si se abusa de ellos a la ligera, tendremos una rutina que cada 2x3 está escaneando la memoria. Esto para según que aplicaciones puede suponer un gran problema de rendimiento.
Aparte si se coge la práctica de hacerlo, el que dé el salto a C, tendrá menos problemas porque allí va a tener que liberar los recursos él mismo Sí o Sí.
Poner en un .lua todas las variables asignandolas a nil, y finalizar con un collectgarbage y cargarlo por ejemplo cuando vas del menú al juego y viceversa.
eso no es buena técnica, poner todas las variables en un fichero aparte para ponerlas a nil.
Se fomenta el uso de variables globales, (que aquí usáis casi todos en exceso), y globales hay que usar las mínimas.(no tengo ganas de entrar en más detalles)
Difícil de depurar, un fichero separado del principal sólo para guardar variables, esto genera errores, por ejemplo si añades más variables, hay que acordarse de añadirlas en el otro fichero, además de renombrarlas en ambos sitios.
De esa forma se liberan TODAS las variables a la vez, con lo cual se vuelve a lo mismo: HAY QUE LIBERARLAS CUANDO NO SE VAYAN A USAR de inmediato
Lo que yo hago es por ejemplo si estas en el menú, creas una funcion que asigne todo lo que necesitas a nil, y cuando salgas del menú la usas.
Por cierto, ya que ha salido, quisiera saber si con las variables locales, una vez ya no se tiene acceso se tienen tambien que "eliminar" o se eliminan solas? Porque es algo que nunca he acabado de comprender bién (Lo de que es una local y cuando se tiene acceso a ella si lo se)
Se liberan de memoria, pero las variables complejas que apunten a estructuras o mapeados de memoria, según el lenguaje, hay que liberarlas de forma explícita.
En el ejemplo que pone XYZ3D, recorre los elementos de un vector liberando cada elemento y luego libera el vector en sí (es decir el apuntador que "apunta" a los elementos). Si él hace esto y Lua tiene un recolector de basura, entonces significa que no siempre se va a liberar correctamente una variable local al salir de una función.
El problema de Lua (y de los lenguajes interpretados), es que no hay tipo de variable, una variable puede ser un entero y luego asignarle una cadena y luego un float... Ahí es difícil sin una buena planificación saber si esa variable debe ser liberada o no. En C por ejemplo, si tienes una variable tipo entero y otra tipo vector de punteros, que contiene un vector de punteros a imágenes por ejemplo, enseguida sabes que la primera no hace falta liberarla de memoria explícitamente.
Basta con collectgarbage() (sin parámetros, fuerza un ciclo de recogida de la basura). En según qué versiones del HM, también está System.memclean() que hace lo mismo, y se supone que también limpia las perrerías que hace el HM en la VRAM (muy, muy poquita cosa, la verdad, si te paras a echar cuentas...).
Ahora bien, ten en cuenta que el programa tiene que ser "limpiable". Es decir, que si lo haces todo, todo, todo con variables globales (por ejemplo), la cantidad limpiada va a ser mínima (algunos bytes por cada llamada a función que hayas hecho, la pila de pendientes del recolector de basura y alguna cosa que me dejo).
En cualquier caso, es buena práctica no fiarse mucho, y "destruir" manualmente todo lo que tengas que destruir, especialmente en el caso de tablas y valores anidados. Es decir, que es mejor hacer un:
for c,v in pairs(tabla) do tabla[c]=nil; end; tabla=nil;
que simplemente tabla=nil; . Esto es así porque, si sólo anularas la tabla, el recolector de basura tendría que hacer dos pasadas para recogerlo todo, mientras que si antes la has iterado con pairs y la has anulado valor a valor, le bastará sólo una pasada para recogerlo todo (siempre que entre en su cupo de trabajo, claro, pero ésa es otra).
Strength is irrelevant. Resistance is future. We wish to improve ourselves.
La fuerza es irrelevante. La resistencia es futuro. Queremos mejorarnos.
Tenga un efecto aun mejor es recomendable poner despues collectgarbage, de modo que el codigo quedaría asi:
--Función--function LimpiarRAM()--Creamos una funcion que usaremos siempre que necesitemos
System.memclean()collectgarbage()--Crea un ciclo de liberacion de la ramend
-----[[7 años en Scenebeta, con la misma ilusión que la del primer día]]----
--Función--function LimpiarRAM()--Creamos una funcion que usaremos siempre que necesitemos
System.memclean()collectgarbage("collect")--Crea un ciclo de liberacion de la ramend
Me decanto por la opcion de
Me decanto por la opcion de quitarlas una a una, y ahora hago eso. Pero tengo una duda:
La duda es, tengo el borrado de funciones arriba, pero al poner nil a select, SE SUPONE que ya la funcion no se cumple, y si pongo el dofile antes, es más de lo mismo, ya no limpia variablews... Entonces eso funciona bien o no...
Saludos y espero haberme expresado bien...
¡Iníciate en Linux fácilmente! Sólo entra aquí y comprueba que distribución se adapta mejor a tí.
Mi review: iPod Touch 4G
ni tan calvo ni con 3 pelucas
Veo que tienes una variable "salir" que seguramente es booleana, y otras que serán enteros. Son tipos simples, o definidos, a esas no tienes que hacerles un nil, Si son globales, porque no tiene sentido eliminarla a no ser que acabes el programa (y se eliminarán sólas), y si son locales porque ya se destruyen al salir de la función.
La "problematicas" son las que tienen gran cantidad de bytes, como imágenes o tablas (arrays).
LuaDiE: Crea en Lua sin teclear código. Compatible HM7, HMv2, LuaPlayer, LuaDEV y PGE.
Es que bg, jugar, comoj,
Es que bg, jugar, comoj, salir y opciones son variables de imágenes, y el programa no se acaba, si no que simplemente se cambia de script, y como no se vuelven a necesitar, se quitan.
Saludos
¡Iníciate en Linux fácilmente! Sólo entra aquí y comprueba que distribución se adapta mejor a tí.
Mi review: iPod Touch 4G
jugar y salir es una
jugar y salir es una variable que contiene una imagen??????
Deduzco que serán las opciones de un menú entonces.
Bueno, yo no lo vuelvo a repetir, que uno parece tonto siempre diciendo lo mismo. Os creáis una variable por opción en vez de tenerlo todo en un vector. Fijaros en el código de XYZ3D, más abajo, la forma elegante de limpiar un vector, eso da claridad de código, lo demás es programar mal.
Yo haría un tutorial sobre el tema, pero por motivos personales, no pienso hacer más tutos aquí. Si podéis echad un vistazo en google sobre trabajar con vectores, veréis como se os facilita la vida (y mucho).
Suerte cuando os salga un trabajo y tengáis que hacer una apliación con 50 opciones.
LuaDiE: Crea en Lua sin teclear código. Compatible HM7, HMv2, LuaPlayer, LuaDEV y PGE.
La verdad
Me es mucho más dificil de comprender de lo que piensas
Aunque sea lo mismo que ha
Aunque sea lo mismo que ha dicho ZYX3D, lo vuelvo a repetir porque tiene mucha razón, y me parece algu muy importante. Es mejor liberar los recursos por uno mismo que usar un recolector de basura. Y después de leerle como se hace en Lua, no es nada complicado, tan sólo poner la variable a un valor nil.
Los recolectores de basura tienen un problema y es que bajan el rendimiento, se pueden usar de forma puntual, pero si se abusa de ellos a la ligera, tendremos una rutina que cada 2x3 está escaneando la memoria. Esto para según que aplicaciones puede suponer un gran problema de rendimiento.
Aparte si se coge la práctica de hacerlo, el que dé el salto a C, tendrá menos problemas porque allí va a tener que liberar los recursos él mismo Sí o Sí.
Un saludo.
LuaDiE: Crea en Lua sin teclear código. Compatible HM7, HMv2, LuaPlayer, LuaDEV y PGE.
Una forma sencilla.
Poner en un .lua todas las variables asignandolas a nil, y finalizar con un collectgarbage y cargarlo por ejemplo cuando vas del menú al juego y viceversa.
Saludos.
eso no es buena técnica,
eso no es buena técnica, poner todas las variables en un fichero aparte para ponerlas a nil.
LuaDiE: Crea en Lua sin teclear código. Compatible HM7, HMv2, LuaPlayer, LuaDEV y PGE.
Ok.
Lo que yo hago es por ejemplo si estas en el menú, creas una funcion que asigne todo lo que necesitas a nil, y cuando salgas del menú la usas.
Por cierto, ya que ha salido, quisiera saber si con las variables locales, una vez ya no se tiene acceso se tienen tambien que "eliminar" o se eliminan solas? Porque es algo que nunca he acabado de comprender bién (Lo de que es una local y cuando se tiene acceso a ella si lo se)
Saludos.
Se liberan de memoria, pero
Se liberan de memoria, pero las variables complejas que apunten a estructuras o mapeados de memoria, según el lenguaje, hay que liberarlas de forma explícita.
En el ejemplo que pone XYZ3D, recorre los elementos de un vector liberando cada elemento y luego libera el vector en sí (es decir el apuntador que "apunta" a los elementos). Si él hace esto y Lua tiene un recolector de basura, entonces significa que no siempre se va a liberar correctamente una variable local al salir de una función.
El problema de Lua (y de los lenguajes interpretados), es que no hay tipo de variable, una variable puede ser un entero y luego asignarle una cadena y luego un float... Ahí es difícil sin una buena planificación saber si esa variable debe ser liberada o no. En C por ejemplo, si tienes una variable tipo entero y otra tipo vector de punteros, que contiene un vector de punteros a imágenes por ejemplo, enseguida sabes que la primera no hace falta liberarla de memoria explícitamente.
LuaDiE: Crea en Lua sin teclear código. Compatible HM7, HMv2, LuaPlayer, LuaDEV y PGE.
Para asegurarme
Será mejor que yo mismo vaya haciendo pruebas mostrando la memoria Ram libre en todo momento y demás.
Gracias por la explicación, +25 (:
Saludos.
collectgarbage()
Basta con collectgarbage() (sin parámetros, fuerza un ciclo de recogida de la basura). En según qué versiones del HM, también está System.memclean() que hace lo mismo, y se supone que también limpia las perrerías que hace el HM en la VRAM (muy, muy poquita cosa, la verdad, si te paras a echar cuentas...).
Ahora bien, ten en cuenta que el programa tiene que ser "limpiable". Es decir, que si lo haces todo, todo, todo con variables globales (por ejemplo), la cantidad limpiada va a ser mínima (algunos bytes por cada llamada a función que hayas hecho, la pila de pendientes del recolector de basura y alguna cosa que me dejo).
En cualquier caso, es buena práctica no fiarse mucho, y "destruir" manualmente todo lo que tengas que destruir, especialmente en el caso de tablas y valores anidados. Es decir, que es mejor hacer un:
for c,v in pairs(tabla) do tabla[c]=nil; end; tabla=nil;
que simplemente tabla=nil; . Esto es así porque, si sólo anularas la tabla, el recolector de basura tendría que hacer dos pasadas para recogerlo todo, mientras que si antes la has iterado con pairs y la has anulado valor a valor, le bastará sólo una pasada para recogerlo todo (siempre que entre en su cupo de trabajo, claro, pero ésa es otra).
Strength is irrelevant. Resistance is future. We wish to improve ourselves.
La fuerza es irrelevante. La resistencia es futuro. Queremos mejorarnos.
La forma que yo se.
Asignando nil a todo lo que ocupe memoria (Variables, tablas, arrays etc.) y poniendo Collectgarbage()
Lo de poner Collectgarbage("Collect") y esas cosas no lo sé mucho.
Mmm...
Es fácil, es con:
Un saludo!
Para que esa funcion
Tenga un efecto aun mejor es recomendable poner despues collectgarbage, de modo que el codigo quedaría asi:
-----[[7 años en Scenebeta, con la misma ilusión que la del primer día]]----
Bien..
Lo tendre en cuenta para usarlo en mi aplicación ;)
Gracias y un saludo!
Nada hombre
Ya verás como se nota ;)
También puede ser así..
;)
Hazme la pregunta que quieras ANONIMAMENTE desde aquí.