• Braulio Madrid

Venciendo al monstruo colector de basura.



Monstruo colector de basura


Este es un problema silencioso que quizás no sepas que estaba ahí, cuando se detiene el juego por instantes cortos es porque el monstruo salió a comerse la basura y esto ocurre porque por lo general hacemos ciertas prácticas que para nosotros los programadores se nos vuelven cómodas pero que tarde que temprano tendremos que corregirlas.


Si una aplicación ocupa toda la memoria disponible, causa que el mismo programa se cierre inesperadamente y borre memoria la memoria ocupada en la RAM. Así que para evitar esto, muchos lenguajes modernos implementan un borrado de los datos en desuso constante almacenados en memoria de forma automática, pero cada vez que esto ocurre genera pequeñas ralentizaciones, la duración depende de la cantidad de datos a borrar.


Unity permite borrar estos datos de manera manual o programar recolecciones de datos más frecuentes si se sabe usar estratégicamente, pero lo ideal sería no usarlo y que este ocurra de manera natural. A continuación tendremos algunos ejemplos que pueden hacer que se acumule mucha basura y como evitarla.


Reemplazar los Bucles Foreach.


Por alguna razón los bucles foreach generan 24 bytes por cada iteración y aunque hay cierto debate de cuál bucle rinde más que los otros, en ciertos casos rinden mejor unos que otros, pero en promedio todos tardan lo mismo, sin embargo foreach genera mayor basura en el colector.


Jamás hagas búsquedas usando cadenas de caracteres.


No importa que comandó uses, evita usar cadenas de caracteres porque al procesador le cuesta comparar el array de caracteres con otro array de caracteres generando así una cantidad de basura en el colector.


  • usar StartCoroutine(Método()); en vez de StartCoroutine(“Método”);

  • usar GetComponent<Tipo>(); en vez de GetComponent(“tipo”);

  • evitar el uso de SendMessage(“Método”, valor);

  • usar go.CompareTag(“tag”); en vez de go.tag == “tag”; dentro de un If

  • usar capas en vez de tags

  • evite cualquier concatenación de cadenas de caracteres en la medida de lo posible.

  • Usar pool de objetos en vez de crear y destruir.

Un pool de objetos es un listado de objetos que se activan y se desactivan, generando la ilusión de que el objeto ha sido destruido. realmente el objeto continúa en memoria, así que nunca va al colector.


Es una manera inteligente de reciclar y el rendimiento se mantiene. en la tienda hay varios disponibles, personalmente uso EZ-Pool.


Usar otro sistema de mensajes diferente al SendMessage() que usa Unity.

SendMessage() es bastante ineficiente, su metodo de busqueda por el uso de cadenas de caracteres, por otra parte no funciona como un envío de mensajes y recepción de mensajes, donde tienes que establecer un método dispuesto a la recepción. SendMessage se envía el mensaje a todos los objetos en escena, lo que hace que entre mayor cantidad de objetos mayor la demora, para solucionar este problema hay un asset en la tienda llamado Temaran Messenger. que es 10 veces más rápido.


Evite en lo posible la creación procedural de objetos y evite hacerlo rápidamente, esto aumenta el consumo de memoria drásticamente, cree los objetos por conjuntos en vez objetos individuales, aplique la creación dentro de una corrutina.


Reutilice tantos recursos como sea posible, cree conjuntos o atlas de texturas en vez de texturas individuales, las texturas de color gris en shader aproveche para usar una gráfica por canal. Aplique la construcción modular de assets.


Cree escenarios pequeños y limitados, usar escenarios grandes a parte de ser inmanejable, también lo es para la memoria.


esto es todo por ahora, nos vemos en un próximo blog.

© 2023 por Darkcom. Proudly created with Wix.com | Peñol, Antioquia, Colombia| +57 3113389725 | Politica de privacidad

  • GitHub
  • BMadrid
  • DarkcomDev
  • Darkcom.dev
  • Braulio-Madrid
  • YouTube Darkcom Tech
This site was designed with the
.com
website builder. Create your website today.
Start Now