cocoa - porque - las ong son asociaciones
CoreFoundation vs Fundación (2)
En el desarrollo del iPhone, la velocidad es esencial. Alguien sabe si hay una diferencia de velocidad entre el uso de un tipo CoreFoundation (como CFMutableDictionaryRef) en comparación con un tipo Foundation (su contraparte, NSMutableDictionary).
Creo que manipular el tipo de CF sería más rápido, ya que no tiene que lanzar mensajes de ObjC en tiempo de ejecución, ¿es esto una suposición infundada? ¿Alguien lo ha investigado?
-James
En un sentido técnico, sí, es más rápido, exactamente por esa razón.
En un sentido práctico, no, no es más rápido. Por un lado, la diferencia de velocidad es pequeña . Estamos hablando de milisegundos ahorrados durante la vida de todo el proceso.
El ahorro puede ser mayor en el iPhone, pero sigue siendo la ganancia de velocidad más pequeña que puedes obtener. Es mejor gastar su tiempo en crear un perfil de su aplicación en Instruments e ir a donde le indique y resolver los puntos calientes en su propio código.
Y ahí es donde la Fundación se vuelve más rápida: tu tiempo.
El código que utiliza la función de autorelease de Foundation siempre que sea posible le ahorra mucho tiempo y dolores de cabeza al evitar las fugas de memoria fácilmente evitables (es decir, olvidarse de escribir o no llegar a los mensajes de release ). CF no tiene autorelease, por lo que debe acordarse explícitamente de CFRelease todo lo que cree o copie con él, y cuando olvide o no llegue a ese código (y quiero decir que cuando hablo por experiencia) gastará mucho más. tiempo de caza por la pérdida de memoria. El analizador de estática ayuda, pero nunca podrá atrapar todo.
(Técnicamente puedes liberar objetos de CF, pero el código para hacerlo es terriblemente feo y solo estás reduciendo tu ganancia de velocidad ya minúscula).
Entonces, quédate con la Fundación tanto como sea posible. No exageres con el autorelease; incluso en Cocoa pura, todavía hay ocasiones en las que se justifica la liberación explícita de objetos (en su mayoría, bucles ajustados), y esto se duplica para Cocoa Touch (ya que iOS eliminará su aplicación si asigna demasiada memoria, por lo que querrá liberar mucho) objetos como imágenes lo antes posible). Pero, por lo general, la ejecución automática le ahorra mucho más tiempo del que CF salvará a sus usuarios.
La razón no relacionada con el tiempo es que el código Objective-C, con los nombres de los argumentos (del selector de mensajes) mezclados con los valores, es mucho más fácil de leer que el código basado en la función C. Es posible que esto no haga que tu trabajo avance más rápido, pero ciertamente lo hace más divertido.
Escribir código en las funciones de CF realmente traerá un aumento de rendimiento a su aplicación, sin embargo, hay otro mejor enfoque para mejorar el rendimiento: escribir directamente en el ensamblaje traería aún más beneficios de rendimiento (aunque este es un enfoque extremo).
Las construcciones de lenguaje de alto nivel son preferibles a las de bajo nivel por al menos las razones que Peter Hosey mencionó. A esto podemos agregar la optimización prematura que puede conducir fácilmente al fracaso del proyecto, ya que el desarrollador está más preocupado por los aspectos no funcionales de la aplicación en lugar de los funcionales.
Si, después de tener una aplicación completamente funcional, siente que algunas partes del código tienen cuellos de botella en el rendimiento, puede intentar optimizarlas, reescribiéndolas en construcciones de lenguaje de bajo nivel. Al menos tendrá un punto de comparación con el código actual, para asegurarse de que el código de bajo nivel se comporte como se espera (ya sea que las pruebas manuales o de unidad funcionarán aquí).