Uso de estructuras en Objective-C (para iOS): optimización prematura?

Question

Me doy cuenta de que lo que cuenta como una optimización prematura tiene un componente subjetivo, pero esta es una pregunta empírica o de mejores prácticas.

Al programar para iOS, ¿debería preferir usar struct y typedefs donde el objeto no tiene "comportamiento" (métodos, básicamente)? Mi sensación es que la sintaxis struct es un poco extraña para una persona que no tiene C, pero que debería ser de perfil BAJO. Por otra parte, al probar algunos casos con 50K NSObject instancias, no parece malo (en lo relativo, lo sé). ¿Debo "acostumbrarme a eso" (use structs si es posible) o las instancias NSObject están correctas, a menos que tenga problemas de rendimiento?

El caso típico sería una clase con dos variables de miembro int. He leído que usar una estructura para contener dos instancias NSString (o cualquier subclase NSObject) es una mala idea.

Answer 1

Vaya con objetos comunes hasta que llegue a un cuello de botella de rendimiento cuantificable. He usado código de alto nivel incluso en bucles apretados sin problemas: mensajería, clases de recopilación, grupos de liberación automática, sin problemas.

Answer 2

Un objeto Objective C tiene casi el mismo almacenamiento que una estructura, excepto que es 4 bytes (8 bytes en 64 bit) más grande. Eso es todo, solo un puntero a un lugar donde el tiempo de ejecución contiene toda la información de la clase.

Si está tan apretado en la memoria, pierda los 4 bytes, pero generalmente eso es solo para una gran cantidad de objetos: 50,000 objetos Nsobjects contra estructuras es solo 200k - se obtienen muchas cosas para esos 200k. Para un millón de objetos, el costo se acumulará en un iPhone.

Si desea decir transferir los elementos a openGL o necesita una matriz c para otros fines, entonces otra opción es hacer ONE NSObject que tenga un puntero malloc'ed a todos los 50,000 enteros. Entonces, la sobrecarga de memoria del objetivo c es ~ 0, y puedes encapsular todas las cosas desagradables malloc y free() en las entrañas de un archivo .m.

Answer 3

Para mí, preferiría utilizar objetos regulares porque puede hacer fácilmente un trabajo Objeto con él como retener, liberar, liberar automáticamente. Solo veo algunas estructuras en Cocoa Framework como CGSize, CGRect y CGPoint. Creo que la razón es que están siendo utilizados mucho

Answer 4

Creo que es una buena idea usar estructuras especialmente si se trata de marcos basados ​​en C, dice OpenGL, CoreGraphics, CoreText especialmente cosas que requerirán un par/triple de ints, dobles, chars, etc. (Si ya no están implementados en algunos de Apple Frameworks: CGRect, CGPoint, CTRect, NSRange, etc ...) C cosas se reproducen y se ven mejor con otras C cosas.

No creo que escribiría una subclase de NSObject que contenga un par de entradas. Es casi ridículo. lol.

Answer 5

Struct s con NSObject instancias en ellos son definitivamente una mala idea. Necesita -init y -dealloc para manejar el recuento de retención correctamente. Escribir retain y releases desde el lado de la persona que llama es simplemente una locura. Nunca valdrá la pena.

Struct s con dos int o cuatro double s son casos límite. El framework Cocoa implementa NSRect, NSPoint etc. como una estructura. Pero ese hecho ha confundido a muchos y muchos recién llegados. Honestamente, incluso la distinción entre tipos primitivos y tipos de objetos los confundió.Se vuelve aún confuso para mí cuando se tiene struct s como propiedades de un objeto: no se puede hacer

object.frame.origin.x=10; 

Si usted comienza a hacer sus propias struct s, es necesario recordar cuál es cuál. Eso es otra vez una molestia. Creo que la razón por la que (NSRect etc.) son struct s son básicamente históricas.

Yo preferiría hacer que todos los objetos. Y use la recolección de basura si está disponible.

Y no pregunte a las personas si algo vale la pena optimizar o no. Mídalo usted mismo por instrumentos o lo que sea. Dependiendo del entorno (ppc vs intel, OS X vs iOS, iPad vs iPhone), una forma que era más rápida en un sistema anterior podría ser más lenta en un sistema nuevo.

Answer 6

No veo ningún problema con el uso de estructuras para contener pequeñas cantidades de tipos primitivos (es decir, no objeto) donde no se requiere un comportamiento. Ya hay varios ejemplos de esto en los marcos de Cocoa (CGRect, CGSize, CGPoint, NSRange por ejemplo).

No utilice structs para sostener objetos Objective-C. Esto complica la administración de la memoria en el entorno contado de referencia y puede romperlo por completo en el entorno GC.