No hablo de tiempo sino de consumo de recursos. El tiempo justamente es lo que ganas teniéndolo en singleton, 

Recursos como uso de memoria?

 
 

Cita de: juanma_teso date=1470951322Recursos como uso de memoria?
   

Si claro. En teoría menor tiempo de ejecución, más recursos consumidos y viceversa. El punto de inflexión es lo que se debe encontrar.

iRob, veo que eres que eres de la escuela anti-singleton jajajaja
 

Cita de: iRobb date=1470854566No estoy de acuerdo. Un singleton para todo el app. Esta clase es para mantener la coherencia entre scenes y su carga, pero no para almacenar tropocientos recursos como sonidos o imágenes que al final no serán necesarios todos ellos para esa scene. Y por eso ha de ser pequeña.
   
   
      Debe mantener datos de sesión del player, referencias a otros datos como url's de servicios e INSTANCIAR lo que se necesite para esa scene, y no ir acumulando. Si gestiona las scenes, sabe lo que debe cargar y eliminar cada vez que hay un cambio de ellas.
   

Estoy totalmente de acuerdo en esto que comentas, pero es que eso sería hacer mal uso de un singleton. Los singletons no tienen por qué tener DontDestroyOnLoad, pueden ser instanciados en una escena y que se destruyan junto a ella, si están bien implementados claro... Es como todo, bien usados ofrecen muchas ventajas y un gran desacoplamiento entre los objetos del juego. Mal usados provocan exceso de consumo de memoria o incluso fugas.
 
Yo siempre tengo varios en un proyecto, separados por responsabilidades:
 
Un GameManager, que es el único que persiste entre escenas (con DontDestroyOnLoad). Lo uso para mantener el estado general del juego y pasar valores entre pantallas, pero siempre datos sencillos, nunca prefabs o cosas pesadas.
 
Otro importante para mí es un LevelManager, este se instancia en cada escena y se destruye con ella, Lo uso para mantener el estado del nivel, como si estamos jugando, en pausa, ejecutando una cinemática, etc. Todos los objetos del juego pueden consultar este estado sin necesidad de tener una referencia a él. 
 
Y el más importante de todos, un sistema de mensajería, que al final es otro singleton (no persistente) que a su vez implementa el patrón publicador-suscriptor. Este Messenger es fundamental para que los objetos de la escena estén desacoplados entre sí. Un ejemplo de uso, supongamos que se instancia un nuevo enemigo, éste lo publica en el Messenger y al que le interese que se entere. Para mí, fundamental.
 
En definitiva, yo estoy en contra del mal uso y del abuso, pero si se usan sabiendo lo que llevas entre manos, ofrecen muchas ventajas.

Totalmente de acuerdo. Deberíamos entonces diferenciar entre singleton propiamente como patrón y objetos persistentes entre scenes. Entonces corrijo lo dicho: solamente un singleton persistente para el proyecto y tantos singleton's como se requieran mesurando con conocimiento por scenes.