En el desarrollo de iPhone, la velocidad es esencial. ¿Alguien sabe si hay una diferencia de velocidad entre usar un tipo de CoreFoundation (como CFMutableDictionaryRef) versus un tipo de Foundation (su homólogo, NSMutableDictionary).CoreFoundation vs Foundation
Creo que manipular el tipo de CF sería más rápido ya que no tiene que lanzar mensajes de tiempo de ejecución de ObjC, ¿es esto una suposición infundada? ¿Alguien realmente ha analizado esto?
-James
en un sentido técnico, sí, es más rápido, precisamente 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 guardados durante la vida de todo el proceso.
El ahorro puede ser mayor en el iPhone, pero aún así es la ganancia de velocidad más pequeña que puede obtener. Es mucho mejor dedicar tiempo a crear perfiles de su aplicación en Instruments e ir a donde se lo indique y resolver los puntos conflictivos en su propio código.
Y ahí es donde Foundation se vuelve más rápida: Su tiempo.
El código que usa la función de liberación automática de Foundation siempre que sea posible le ahorra mucho tiempo y dolores de cabeza al evitar fugas de memoria fácilmente evitables (es decir, olvidarse de escribir o no alcanzar los mensajes release). CF no tiene liberación automática, por lo que debe recordar explícitamente CFRelease todo lo que cree o copie con él, y cuando olvide o no llegue a ese código (y me refiero a cuando -hablo por experiencia), gastará mucho más tiempo buscando la fuga de memoria. El analizador estático ayuda, pero nunca podrá capturar todo.
(Es técnicamente posible objetos autorelease CF, pero el código para hacerlo es terriblemente fea y que sólo está diluyendo su aumento de velocidad ya-minúsculo.)
Por lo tanto, se adhieren a la Fundación tanto como posible. No te excedas con la liberación automática; incluso en Cocoa puro, todavía hay momentos en los que está garantizado la liberación explícita de objetos (la mayoría de los bucles apretados), y esto se duplica para Cocoa Touch (ya que iOS matará su aplicación si asigna demasiada memoria, por lo que querrá liberar grandes objetos como imágenes lo más pronto posible). Pero, por lo general, la liberación automática le ahorra mucho más tiempo de lo que CF salvará a sus usuarios.
El motivo no relacionado con el tiempo es que el código Objective-C, con nombres de argumento (del selector de mensajes) mezclado con valores, es mucho más fácil de leer que el código basado en la función C. Esto puede no hacer que su trabajo vaya más rápido, pero ciertamente lo hace más divertido.
Cuando uso objetos CF, siempre uso un contenedor C++ cuyo destructor se encarga de CFRelease, y que también tiene constructores de copia y que hacen lo correcto. Recordar poner un objeto CF en ese envoltorio tan pronto como se crea no es más difícil que recordar soltar automáticamente los objetos de Foundation, al menos para mí. Pero estoy de acuerdo en que cualquier diferencia de tiempo es probablemente mínima, y que uno debe permitir que un perfilador guíe los esfuerzos de optimización. – JWWalker
Estoy buscando convertir una tonelada de datos de un formato de texto estructurado personalizado en objetos verdaderos para que el iPhone los use. Sin embargo, voy a marcar esto como respondido. – grmartin
@JWWalker: si va a ajustar un objeto CoreFoundation, ¿por qué no simplemente ajustarlo en Objective-C? De hecho, las clases con análogos de FQ suelen ser solo envoltorios de la clase CF. (Por ejemplo, 'NSMutableDictionary' es un clúster de clase que a menudo devuelve un objeto cuya clase real es' NSCFDictionary', que es básicamente una clase ObjC que usa un CFDictionary como su almacén de respaldo.) – mipadi
Escribir código en las funciones de CF proporcionará un impulso de rendimiento a su aplicación, sin embargo, hay otro enfoque mejor para mejorar el rendimiento: escribir directamente en el ensamblaje aportarí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 a la falla del proyecto, ya que el desarrollador está más preocupado con 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 de rendimiento, puede tratar de optimizarlas volviéndolas a escribir 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 unitarias funcionen bien aquí).
Cuando dice que la velocidad es esencial, ¿se refiere a la velocidad de desarrollo o la velocidad de la aplicación desarrollada? – JeremyP
Velocidad en la aplicación en sí. – grmartin