Unity depende en el CPU (altamente optimizado para la parte SIMD de este, como SSE en X86 o NEON en ARM) para skinning, batching, física, scripts de usuario, partículas, etc.
El GPU es utilizado para shaders, drawcalls, efectos de imagen.
Una gran cantidad de problemas (80%) son producidos por unas causas claves (20%). Usted puede utilizar el perfilador del Editor para identificar la mayoría de llamadas de funciones intensivas al procesador y optimizarlas primero. A menudo, optimizar unas pocas funciones claves nos puede dar un aumento significativo en la velocidad de ejecución en general.
Usted debería asegurarse que las funciones solo son ejecutados cuando sean realmente necesarias. Por ejemplo, usted puede utilizar eventos como OnBecameVisible y OnBecameInvisible para detectar cuando un objeto no puede ser visto y evitar actualizarlo. Las Coroutines pueden ser una manera útil de llamar código que necesite actualizaciones regulares pero no necesitar correr cada cuadro:-
// Do some stuff every frame:
void Update () {
}
//Do some stuff every 0.2 seconds:
IEnumerator SlowUpdate () {
while (true) {
//do something
yield return new WaitForSeconds (0.2f);
}
}
Usted puede utilizar la clase .NET System.Threading.Thread para correr cálculos pesados en un thread separado. Esto el permite a usted correr múltiples núcleos pero tenga en cuenta que el API de Unity no es seguro para thread- usted necesita buffer los inputs y resultados y leer y asignarlos al thread principal con el fin de utilizar las llamadas de la API de Unity.
No todo el código del usuario es mostrado en el Profiler (perfilador). Pero usted puede utilizar Profiler.BeginSample y Profiler.EndSample para hacer que el código del usuario requerido aparezca en el perfilador.
El Perfilador del Editor de Unity no puede mostrar datos del GPU por ahora. Nosotros estamos trabajando con fabricantes de hardware para hace que suceda con dispositivos Tegra siendo los primeros en aparecer en el perfilador del Editor.
PowerVR es un renderizador deferred en tejas, por lo que es imposible obtener tiempos de GPU por draw call. No obstante, usted puede obtener tiempos GPU para la escena entera utilizando el profiler (perfilador) integrado de Unity (el que imprime resultados a los output de Xcode). Las herramientas de Apple actualmente solo pueden decir qué tan ocupado el GPU y su partes están, pero no da tiempo en milisegundos.
PVRUniSCo da ciclos para el shader entero, y aproxima ciclos por cada linea en el código shader. Windows & Mac! Pero no va a coincidir con lo que los drivers de Apple están haciendo exactamente igual. Sin embargo, es una buena medida de estadio.
On Tegra, NVIDIA proporciona unas herramientas de rendimiento excelentes que hace todo lo que usted quiera - el tiempo del GPU por draw call, Ciclos por shader, textura 2x2 Force, un rectángulo de vista nulo, corre en Windows, OSX, Linux. PerfHUD ES no funciona fácil con dispositivos de un consumidor, usted necesita la tabla de desarrollo de NVIDIA.
Qualcomm proporciona un excelente Perfilador Adreno (Windows solamente) que es solamente para Windows, pero funciona con dispositivos de consumo! Éste tiene de características gráficas Timeline, captura de frame, depuración de Frame, llamados API, analizador de Shader, edición en vivo.
El profiler (perfilador) interno da una buena visión general por módulo:
Puertos que usa el profiler de Unity:
Estos deberían ser accesibles desde el nodo de network. Esto es, los dispositivos que usted está intentando perfilar deberían ser capaces de ver estos puertos en la maquina con el Editor de Unity con el Profile prendido.
Hay dos tipos de memoria, memoria Mono y memoria de Unity.
La memoria Mono maneja objetos scripts, envolturas para objetos de Unity (game objects, assets, componentes, etc). El Garbage Collector limpia cuando la asignación no encaja en la memoria disponible o un llamado System.GC.Collect().
La memoria es asignada en bloques heap. Más se puede asignar si los datos no pueden encajar en el bloque asignado. Los bloques heap se mantendrán en Mono hasta que la app se cierre. En otras palabras, Mono no suelta cualquier memoria utilizado al OS (Unity 3.x). Una vez usted asigne cierta cantidad de memoria, se reserva para mono y no está disponible para el OS. cuando usted lo suelta, se mantendrá disponible internamente para Mono solamente y no para el OS. el valor de memoria heap en el Profiler (perfilador) solamente aumentará, nunca va a disminuir.
Si el sistema no puede encajar nuevos datos al bloque heap asignado, el Mono llamada un “GC” y puede asignar un nuevo bloque heap (por ejemplo, debido a la fragmentación).
“Too many heap sections” significa que usted se ha quedado sin memoria Mono (debido a la fragmentación o un uso fuerte).
Utilice System.GC.GetTotalMemory para obtener la memoria Mono utilizada localmente.
El consejo general es, utilice una asignación tan pequeña como sea posible.
La memoria de Unity maneja los datos de Assets (Textura, Meshes, Audio, Animación, etc), Game Objects, internos del Motor (Renderización, Partículares, Física, etc).
Utilice Profiler.usedHeapSize para obtener la memoria de Unity utilizada totalmente.
No hay herramientas todavía pero usted puede utilizar lo siguiente.
Usted también puede hacer su propia herramienta utilizando llamadas del API de Unity:-
FindObjectsOfTypeAll (type : Type) : Object[]FindObjectsOfType (type : Type): Object[]GetRuntimeMemorySize (o : Object) : intGetMonoHeapSizeGetMonoUsedSizeProfiler.BeginSample/EndSample - perfile su propio códigoUnloadUnusedAssets () : AsyncOperationSystem.GC.GetTotalMemory/Profiler.usedHeapSizeReferencias a los objetos cargados - No hay forma de averiguar esto. Una solución alternativa es “Encontrar referencias en la escena” para variables públicas.
OnGUI() en móviles: dispara varias veces por frame, re-dibuja completamente la vista y crea muchos llamados de asignaciones de memoria que requieren que el Garbage Collection sea invocado.System.GC.Collect() Usted puede utilizar esta función .Net cuando sea bueno tener un hiccup.En algunos puntos un juego podría fallar con “out of memory” (falta de memoria) aunque en teoría debería encajar perfecto. Cuando esto sucede compare el footprint de memoria de su juego y el tamaño de memoria asignada cuando la falla sucede. Si los números no son similares, entonces hay un pico de memoria. Esto se puede dar a: