Me pregunto principalmente sobre el efecto que la recolección de basura tendría en el rendimiento. ¿Se desaconseja el uso de la recolección de basura para las aplicaciones de lanzamiento?¿Se utiliza la recolección de basura en la calidad de producción de las aplicaciones de cacao?
Otra preocupación que puedo pensar es que el uso de recolección de basura podría llevar a una programación más descuidada.
¿Utiliza la recolección de basura en sus aplicaciones?
La recolección de basura se utiliza en muchas aplicaciones de calidad de producción. Xcode, Automator, Preferencias del Sistema y varias otras aplicaciones del sistema están sometidas a GC, y puede esperar que esa tendencia continúe a lo largo del tiempo.
Además, muchos desarrolladores han adoptado GC y lo están utilizando exclusivamente en sus aplicaciones. Las nuevas versiones de Intuit de Quicken y QuickBooks para Mac son basura recolectada, por ejemplo.
Hay una serie de ventajas de GC, también. Fuera de mi cabeza y de mi experiencia personal:
hace que sea más fácil el subprocesamiento; una asignación simple es una declaración atómica de propiedad
descarga una gran cantidad de administración de memoria a otros núcleos; es naturalmente concurrente y descarga a un cálculo montón desde el hilo principal (o hilos de cálculo)
En muchos casos, la asignación y desasignación puede suceder enteramente dentro del contexto de un hilo, eliminando así cualquier necesidad de sincronización global o de bloqueo
el colector se ha vuelto más rápido con cada versión de Mac OS X y esa tendencia continuará (al igual que con el resto del sistema). Al descargar más de la carga computacional de su aplicación a los marcos provistos por el sistema, su aplicación obtendrá más y más de las optimizaciones para el sistema subyacente.
porque el recopilador tiene un conocimiento profundo del gráfico de objetos (de los punteros entre los objetos), en la memoria hace que el análisis y la depuración sean mucho más fáciles. En lugar de "¿de dónde viene este puntero colgante?", La pregunta ahora es "¿Me da una lista de razones por las que este objeto se queda más tiempo del que creo que debería?".
Esto no quiere decir que no hay trabajo que hacer para que su aplicación funcione de manera óptima bajo GC. ¡Ciertamente hay tales tareas!
La recolección de basura ha existido desde la década de 1960 y se utiliza en muchas aplicaciones lanzadas. Todas las aplicaciones .NET usan recolección de basura. Apple usa libauto en Xcode.
La recolección de basura generalmente conduce a aplicaciones de mejor calidad en Cocoa ya que el desarrollador se libera de la carga de administración de memoria. ¡Hay toneladas de aplicaciones de Cocoa que se escapan! (aunque puede no tener una cantidad significativa de memoria)
Tiendo a usar gc ya que puedo cambiar mis aplicaciones más rápido y ¡no tengo que preocuparme por enviar mensajes a objetos zombies!
También hay toneladas de aplicaciones recolectadas de basura que se filtran. Es muy probable que goteen menos. – Lothar
Uso GC cada vez que puedo, porque el mejor código de todos es el código que no tiene que escribir en primer lugar. Además, como señaló Bbum anteriormente, ejecutar bajo GC significa que tiene mucha más información disponible para el análisis de rendimiento, en caso de que necesite depurar los cuellos de botella.
La recolección de basura se recomienda para cualquier aplicación nueva de Cocoa, y Apple come su propia comida para perros usándola en Xcode. El rendimiento es una situación interesante, porque si bien es probable que consuma más ciclos de CPU en general, la aplicación puede terminar siendo más rápida en algunas áreas debido a la multiplicidad de capas del colector y la simplificación de los métodos de acceso.
Las computadoras están hechas para hacer el trabajo por nosotros. El recuento de referencias de Cocoa generalmente es fácil de administrar, pero la recolección de basura es una cosa más que puede hacer ahora: ¡deje que la máquina haga el trabajo para que pueda concentrarse en las cosas que importan!
Al igual que los demás, recomiendo utilizar GC. ¡La sobrecarga de rendimiento generalmente es insignificante! No necesito repetir los beneficios según lo manifestado por otros usuarios.
Sin embargo, recomendaría encarecidamente que las bibliotecas de escritura, a diferencia de las aplicaciones, también se ejecuten en un modo que no sea de GC. Algunos entornos no pueden ejecutar código de GC, siendo el iPhone el más notable; así que si usted creó una biblioteca interna para usted, que prevé volver a utilizarla más adelante para una aplicación de iPhone, entonces recomendaría diseñarla para que funcione en un entorno que no sea de GC.
¡La conversión de un código de GC a un código que no es de GC es mucho más difícil que a la inversa!
A pesar de que algunos entornos (como iPhone y pre-Leopard) no son compatibles con GC, puede compilar bibliotecas en modo dual. Se necesita un poco de trabajo extra, pero ciertamente es posible. Lo hice por el framework de código abierto CHDataStructures. –
@Quinn, no puedo estar más de acuerdo. Sin embargo, aclaré mi publicación para indicar que quería decir que las bibliotecas deberían escribirse para ser utilizables en entornos que no sean GC. – notnoop
Buena información. ¡Gracias! – calvinlough
Vale la pena señalar que la recolección de basura ha quedado obsoleta en 10.8. –
Ahora vale la pena señalar que 10.11 será la última versión de OS X para incluir el tiempo de ejecución de la recolección de elementos no utilizados. Las aplicaciones que usan recolección de basura pueden no ejecutarse correctamente o no funcionar en 10.12. – Andrew