Un análisis técnico del blog de Aras Pranckevičius examina por qué las funciones matemáticas de UnityEngine.Mathf (Sqrt, Sin, Cos, Log, Pow, etc.) son más lentas que sus equivalentes en System.MathF. La razón principal es que el runtime Mono de Unity realiza todos los cálculos en doble precisión, aunque los datos se almacenen en coma flotante de 32 bits, lo que genera constantes conversiones float⇄double. System.MathF, introducido en .NET Core 2.0 (2017), llama directamente a implementaciones nativas en float.
El autor mide un bucle de 10 millones de raíces cuadradas en un Ryzen 5950X con Unity 6000.0.76. En el editor, UnityEngine.Mathf tarda 282 ms frente a 186 ms de System.MathF; en modo Release, 242 ms frente a 149 ms. En builds con IL2CPP, ambos se igualan a 35 ms, lo que sugiere que IL2CPP detecta y optimiza la precisión simple. Con el compilador Burst, los tiempos caen a 34-66 ms, pero System.MathF no es compatible con Burst y provoca errores de compilación. El paquete Unity.Mathematics ofrece un rendimiento ligeramente mejor que Mathf clásico, salvo bajo IL2CPP.
El artículo incluye tablas comparativas con C# Mono, .NET 10 y C++ (/O2), cuyo techo se sitúa en 35 ms. También muestra el código ensamblador generado por Mono y documenta casos donde los resultados impresos (24212990000000.0) no existen como float de 32 bits, evidencia adicional de las conversiones implícitas a doble precisión. La conclusión: aunque el consejo del tuit original es acertado, la elección entre Mathf, System.MathF y Unity.Mathematics depende del backend de scripting (Mono, IL2CPP, Burst) y de si se necesita compatibilidad con Burst.