Utilizzo di strutture in Objective-C (per iOS): ottimizzazione prematura?

Question

Mi rendo conto che ciò che conta come ottimizzazione prematura ha una componente soggettiva, ma questa è una domanda empirica o delle migliori pratiche.

Durante la programmazione per iOS, dovrei preferire l'utilizzo di struct e typedef in cui l'oggetto non ha "comportamento" (metodi, in pratica)? La mia sensazione è che la sintassi struct sia un po 'strana per una persona non C, ma che dovrebbe essere WAY profilo inferiore. Poi di nuovo, testando alcuni casi con istanze di 50K NSObject, non sembra male (relativo, lo so). Dovrei "abituarmi" (usa le strutture dove possibile) o sono le istanze NSObject ok, a meno che non abbia problemi di prestazioni?

Il caso tipico sarebbe una classe con due variabili membro int. Ho letto che usare una struttura per contenere due istanze NSString (o qualsiasi sottoclasse NSObject) è una cattiva idea.

Answer 1

Andare con oggetti regolari fino a quando si colpisce un collo di bottiglia delle prestazioni misurabili. Ho usato codice di alto livello anche in loop di gioco stretti senza problemi: messaggistica, classi di raccolta, pool di autorelease, nessun problema.

Answer 2

Un oggetto Objective C ha quasi la stessa memoria di una struttura, ad eccezione di 4 byte (8 byte su 64 bit) più grandi. Ecco, un solo puntatore in un punto in cui il runtime contiene tutte le informazioni sulla classe.

Se sei così stretto sulla memoria, allora perdi i 4 byte, ma di solito è solo per un gran numero di oggetti: 50.000 Nsobjects vs structs è solo 200k - ottieni un sacco di cose per quel 200k. Per un milione di oggetti, il costo si sommerà su un iPhone.

Se si desidera trasferire gli elementi in openGL o richiedere un array c per altri scopi, un'altra opzione consiste nel rendere ONE NSObject che ha un puntatore malloc su tutti i 50.000 numeri interi. Quindi l'overhead della memoria dell'obiettivo c è ~ 0, e puoi incapsulare tutte le cose brutte malloc e free() nelle interiora di un file .m.

Answer 3

Per quanto mi riguarda, preferirei utilizzare gli oggetti normali perché si può facilmente eseguire il lavoro su oggetti come conservare, rilasciare, autorelease. Vedo solo poche strutture in Cocoa Framework come CGSize, CGRect e CGPoint. Penso che il motivo sia che vengono utilizzati molto

Answer 4

Credo sia una buona idea usare le strutture specialmente se si hanno a che fare con framework basati su C, diciamo OpenGL, CoreGraphics, CoreText roba speciale che richiederà un paio/triplo di int, double, char, ecc. (Se sono già implementati in alcuni framework Apple: CGRect, CGPoint, CTRect, NSRange, ecc ...), la roba di C gioca e ha un aspetto migliore con altre cose di C.

Non penso che scriverei una sottoclasse di NSObject contenente un paio di ints. È quasi ridicolo. lol.

Answer 5

Struct s con NSObject istanze in loro sono decisamente una cattiva idea. Sono necessari -init e -dealloc per gestire correttamente il conteggio dei fermi. Scrivere retain e releases dal lato del chiamante è semplicemente folle. Non pagherà mai.

Struct s con due o quattro double s sono casi limite. Lo stesso framework Cocoa implementa NSRect, NSPoint ecc. Come una struttura. Ma questo fatto ha confuso molti e molti nuovi arrivati. Onestamente, anche la distinzione tra tipi primitivi e tipi di oggetto li ha confusi.Diventa ancora confuso per me quando si dispone di struct s come proprietà di un oggetto: non si può fare

object.frame.origin.x=10; 

Se si inizia a fare i propri struct s, è necessario ricordare che si tratta. È di nuovo una seccatura. Penso che il motivo per cui essi (NSRect ecc.) Sono struct s sono fondamentalmente storici.

Preferirei creare tutto. E usa la garbage collection se disponibile.

E, non chiedere alle persone se qualcosa vale la pena di ottimizzare o meno. Misurala tu stesso con gli strumenti o qualsiasi altra cosa. A seconda dell'ambiente (ppc vs intel, OS X vs iOS, iPad vs iPhone) un modo più veloce in un sistema precedente potrebbe essere più lento in un nuovo sistema.

Answer 6

Non vedo alcun problema con l'utilizzo delle strutture per contenere piccole quantità di tipi primitivi (vale a dire non oggetto) in cui non è richiesto alcun comportamento. Ne esistono già diversi esempi nei framework Cocoa (CGRect, CGSize, CGPoint, NSRange per esempio).

Non utilizzare le strutture per contenere oggetti Objective-C. Complifica la gestione della memoria nell'ambiente conteggiato di riferimento e potrebbe interromperla completamente nell'ambiente GC.