No pude encontrar un estudio objetivo sobre el impacto del rendimiento ARC en un proyecto de la vida real.El documento oficial dice

El compilador elimina eficazmente muchas llamadas de retención / liberación extrañas y se ha invertido mucho esfuerzo en acelerar el tiempo de ejecución de Objective-C en general. En particular, el patrón común de "devolver un objeto retenido / lanzado automáticamente" es mucho más rápido y en realidad no coloca el objeto en el conjunto de autorelease, cuando el autor del método es el código ARC.

que ha sido transmitido / deformado por los fanáticos de la tecnología a "ARC es más rápido".

Lo que sé con certeza es lo que medí. Recientemente hemos migrado nuestro proyecto de iOS a ARC e hice algunas mediciones de rendimiento antes / después en un área de código intensivo de la CPU (código de producción, compilado con el-Os bandera, por supuesto).

Observé una regresión de rendimiento del 70% (sí, 70%). UtilizandoInstrumentos para rastrear los eventos de retención / liberación, me di cuenta de que el compilador introduce MUCHOS pares de retención / liberación en el área donde no lo haría (en un entorno de ARC anterior). Básicamente, cualquier temporal se vuelve fuerte. Esa es, creo, la fuente de la regresión del rendimiento.

El código original, antes de la migración, ya estaba bastante optimizado. Apenas hubo autorelease hecho. Por lo tanto, había poco espacio para mejorar cambiando a ARC.

Por suerte,Instrumentos pude mostrarme la retención / liberación más costosa introducida por ARC y pude desactivarla utilizando __unsafe_unretained. Esto mitiga ligeramente la regresión del rendimiento.

¿Alguien tiene alguna información sobre esta u otra técnica para evitar la pérdida de rendimiento? (aparte de desactivar ARC)

Gracias.

EDIT: No estoy diciendo que ARC sea malo debido al impacto en el rendimiento. La ventaja de usar ARC es en gran medida superior a la regresión de rendimiento (en nuestro código, la regresión no tuvo ningún efecto visible, por lo que la dejé pasar). Considero ARC una muy buena tecnología. Nunca volveré a MRC. Estoy haciendo esta pregunta más por curiosidad.

Estoy un poco molesto por la gran mayoría de los blogs sobre el tema (comoaquí y ahi) que más o menos da la impresión de que el código ARC será más rápido que el código MRC (algo que creí antes de ponerlo en mis manos). Y realmente tengo la sensación de que este no es el caso fuera de algunos puntos de referencia micro. En el mejor de los casos, puede esperar estar a la par con MRC, no más rápido. Hice algunas otras pruebas simples que involucran la manipulación de objetos (como contar palabras en un documento). Cada vez que el ARC fue más lento (no fue tan malo como la regresión de rendimiento del 70% que estaba hablando inicialmente)

\ comenzar {sarcasmo}

De hecho, el doc. Mencionado respondió la pregunta:

¿Es ARC lento?

Depende de lo que estés midiendo, pero generalmente "no".

que obviamente debe entenderse como

\ begin {parodia}

Bueno ... hum ... no podemos decir que sea más lento porque es un nuevo techno genial y nos gustaría que lo adoptes. Así que respondemos "no" con comillas dobles solo para evitar una acción de clase. Y deja de hacer preguntas estúpidas.

\ end {parodia}

\ end {sarcasmo}