Code benchmarks Unity3D

#33 con array no sucede, es con list. Se debe tener en cuenta dada la magnitud de pérdida.

Mola la idea del hilo, también deberías tener en cuenta que ciertas técnicas hacen allocations y otras no, el GC en unity es de las cosas que te pueden matar el performance.

#41 items.Count manipula la comparación porque la implementación óptima del for es mediante el cacheo de items.Count a una variable vs implementación interna del foreach.

Aun así... ahí va con el items.Count...

using UnityEngine;
using System.Linq;
using System.Diagnostics;
using System.Collections.Generic;


public class Main : MonoBehaviour
{
	void Start()
	{
		int iterations = 50000;
		List<string> items = Enumerable.Range(0, 1000).Select(i => i.ToString()).ToList();

	Stopwatch forWatch = Stopwatch.StartNew();

	for (int i = 0; i < iterations; i++)
	{
		for (int j = 0; j < items.Count; j++)
		{
			string x = items[j];
		}
	}

	forWatch.Stop();

	Stopwatch forEachWatch = Stopwatch.StartNew();

	for (int i = 0; i < iterations; i++)
	{
		foreach (string j in items)
		{
			string x = j;
		}
	}

	forEachWatch.Stop();

	print (forWatch.Elapsed + " :for");
	print (forEachWatch.Elapsed + " :forEach");
}
}

PD: Abres el Unity, pegas tu propio código (con el items.Count), le das a play y después lo cascas...

#43 Un bunny test consiste en un stress test de elementos en una escena para controlar el rendimiento de esta. Es como si en un mmo, en la zona inicial metieras a cientos o miles de jugadores para comprobar todas las conexiones y peticiones de estos jugadores al server analizando los tiempos de respuesta. O en uno de naves espaciales, cuantos cohetes, bolas, naves y otras piezas puede contener la escena antes de que los FPS decaigan.

En el caso que me ocupa. Cada animadora está formado por unos 50-100 sprites, uno por cada parte del cuerpo o elemento movible. Animator, el SDK para hacerlos funcionar para que no se solapen los sprites. A ver, el SDK usado tiene demasiada carga y por ello solo se pueden mantener ese cierto número de elementos en pantalla. No está pensado para contener tal número de elementos.

Viene muy bien para móviles y novelas gráficas pero no para crear animaciones de movimiento con los que un personaje pueda moverse por la pantalla.

Yo soy un absolut newbe en esto de forear en desarrollo, y visto que algunos traen ya el revolver fuera, no parece este el saloon más adecuado en el que meterse a comentar, pero me mola lo que leo, llevo dos años intentando abrir los ojos con que a lo mejor el game-dev no es mi sitio por el nivel, y entre 3
notas (seguramente ingenieros) que veo que habeís posteado en menos de dos días por aquí, ya me estais echando xD
Ánimo con esos test, aunque bien me apunto esa cita de la prematura optimización

#49 jajajajajaja acabas de callarle la boca y los pensamientos a muchos, creo

#53 pues yo no me lo esperaba, me esperaba un preprocesado + clean.

#53 Pues si, siempre se recomienda eliminar todos los métodos del ciclo de Unity que no estén en uso porque se intentan evaluar, vamos es algo que recuerdo aprender casi desde el principio. No lo digo por darme aires de nada, si no porque debe de estar remarcado por ahí en la documentación o similar.

De hecho es peligroso para ciertas prácticas donde la gente usa componentes a modo de etiquetas ( por ejemplo, hacer la clase Libro.cs, vacía con el Start y Update por defecto simplemente para recoger luego con un Getcomponent todos los "Libros")

Borradlos siempre!

De todas formas, siempre está bien ilustrar el impacto que tiene, 20K GO tampoco es un número normal, pero aunque con 100 GO la diferencia no sea tanta, siempre es bueno recortar

También deberías notar mejoras si eliminas el Start, solo que al ser de llamada única y al principio el impacto puede parecer / ser menor

Update()
Update(), LateUpdate() and other event functions look like simple functions, but they have a hidden overhead. These functions require communication between engine code and managed code every time they are called. In addition to this, Unity carries out a number of safety checks before calling these functions. The safety checks ensure that the GameObject is in a valid state, hasn't been destroyed, and so on. This overhead is not particularly large for any single call, but it can add up in a game that has thousands of MonoBehaviours.

For this reason, empty Update() calls can be particularly wasteful. We may assume that because the function is empty and our code contains no direct calls to it, the empty function will not run. This is not the case: behind the scenes, these safety checks and native calls still happen even when the body of the Update() function is blank. To avoid wasted CPU time, we should ensure that our game does not contain empty Update() calls.

Para el runtime del editor podría ser justificable (que tampoco)... Pero bueno, teniendo en cuenta la interminable lista de BUGs pendientes que tienen, seguramente el no pre procesar les alivie de problemáticas posteriores.

#59 no aplica, estamos hablando de un método específico que además es inherente al engine, el Update.