¿Es la agrupación de objetos pequeños más eficiente que el recolector de basura Java de Android?

Por lo tanto, estaba leyendo esto: http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html que dice: "Anuncio de servicio público: la agrupación de objetos es ahora una pérdida de rendimiento grave para todos, Más pesado de objetos, e incluso entonces es difícil conseguir sin introducir cuellos de botella de concurrencia ", y lo tomó a su valor nominal. El artículo habla de GC generacional, desasignación, asignación de hilos locales y análisis de escape.

Sin embargo, sólo tenía una pequeña voz en mi cabeza me preguntan: "¿Pero esto es cierto de la aplicación de recolector de basura en Android?" Y no sé la respuesta. Ni siquiera sabría cómo encontrar la respuesta.

Recuerdo que el GC funcionaba con menos frecuencia en mis aplicaciones para Android cuando implementé la agrupación de objetos pequeños que se usaban con frecuencia. No estoy seguro de si eso significa una aplicación más rápida .. Además, GC corrió más a menudo sin pooling (de acuerdo con logcat), así que supongo que la implementación de Android de la GC pierde a la puesta en común .. Pero esta suposición tiene muy poco respaldo porque no me di cuenta Cualquier diferencia de rendimiento significativa con o sin agrupación.

Así que .. ¿Alguien aquí sabe si la agrupación es más eficiente que la GC de Android para los objetos pequeños que se utilizan a menudo?

¿Alguien aquí sabe si la agrupación es más eficiente que la GC de Android para objetos pequeños usados con frecuencia?

Eso depende de cómo se mida "eficiente", "pequeño" y "a menudo".

El agrupamiento de objetos se utiliza en varios lugares dentro de Android, tales como:

Toda la estructura del Adapter para AdapterView ( ListView y parentesco) está diseñada alrededor de grupos de objetos, esta vez para objetos relativamente pesados (por ejemplo, una fila ListView puede ser fácilmente decenas de KB)
SensorEvent objetos SensorEvent se reciclan, esta vez para objetos ligeros usados potencialmente docenas de veces por segundo
AttributeSet objetos AttributeSet se reciclan, como parte de View inflation

y así.

Algo de eso se basó en las primeras versiones de Dalvik en las primeras versiones de Android, cuando estábamos apuntando a CPU de 100MHz con un lenguaje puramente interpretado y un motor GC bastante ingenuo.

Sin embargo, incluso hoy en día, la agrupación de objetos tiene una gran ventaja más allá del rendimiento inmediato: la fragmentación de montón.

El motor GC de Java es un recolector de recolección de compactación, lo que significa que los bloques contiguos de espacio de montón libre se combinan en bloques mucho más grandes. El motor GC de Dalvik es un recolector de basura que no compacta, lo que significa que un bloque que asigna nunca se convertirá en parte de un bloque más grande. Aquí es donde muchos desarrolladores se atornillan con la gestión de mapa de bits – el OutOfMemoryError que obtienen no es porque el montón está fuera de sitio, pero que el montón no tiene ningún bloque lo suficientemente grande para la asignación deseada, debido a la fragmentación de montón.

Las agrupaciones de objetos evitan la fragmentación del montón, simplemente evitando que los objetos agrupados se vuelvan a recolectar basura y no asignen nuevos objetos a la agrupación muy a menudo (sólo si la agrupación necesita crecer debido a un uso simultáneo excesivo).

Los desarrolladores de juegos han utilizado durante mucho tiempo la agrupación de objetos en Android, que se derivaba de la espalda cuando la recolección de basura de Android no era concurrente, "detener el mundo" cuando GC se llevó a cabo. Ahora, la mayoría de los dispositivos Android utiliza un colector de basura concurrente, que alivia el dolor aquí algunos.

Por lo tanto, la agrupación de objetos es definitivamente todavía una técnica relevante. En general, sin embargo, lo veo como algo para emplear como una reacción a un problema detectado (por ejemplo, Traceview mostrando demasiado tiempo en GC, Traceview mostrando demasiado tiempo en constructores de objetos, MAT mostrando que tiene un montón de montón, pero usted Get OutOfMemoryErrors ). La excepción sería el desarrollo de juegos: los desarrolladores de juegos probablemente tendrán su propia heurística para cuando se necesite todavía la agrupación con modernos dispositivos Android.

Hay una falacia en su razonamiento. El GC que se ejecuta con más frecuencia no indica algún tipo de rendimiento disminuido. Aquellos recorridos GC más frecuentes también podrían ser mucho más rápidos y más cortos que los menos frecuentes que tienen que atravesar la piscina de objetos.

Dicho esto, hice algunas investigaciones y aquí hay algunos pensamientos … Hace un par de años, mi teléfono móvil tenía un solo núcleo. Ejecutar el GC significó cambiar de la actividad al hilo del GC. Incluso con CG concurrente y múltiples núcleos (los dispositivos modernos tienen 2-5 afaik), podría haber pausas leves.

Pre-asignar todo lo que el usuario puede necesitar para la siguiente secuencia de interacciones se sugiere como una buena idea para los juegos. Esencialmente siguiendo el mantra de las aplicaciones en tiempo real que están menos preocupados por el rendimiento general en comparación con tener un rendimiento mensurable coherente durante la parte de la experiencia de usuario de la aplicación.

http://developer.android.com/training/articles/perf-tips.html