Я понимаю, что то, что считается преждевременной оптимизацией, имеет субъективную составляющую, но это эмпирический или лучший опыт.
При программировании для iOS я должен использовать struct и typedefs, где объект не имеет "поведения" (в основном, методов)? Я чувствую, что синтаксис struct немного странный для человека, не относящегося к C, но это должен быть нижний профиль WAY. Опять же, тестируя некоторые случаи с 50K NSObject экземплярами, это не кажется плохим (относительный, я знаю). Должен ли я "привыкнуть к нему" (если возможно, использовать структуры) или NSObject экземпляры, если у меня нет проблем с производительностью?
Типичным случаем будет класс с двумя переменными-членами int. Я читал, что использование структуры для хранения двух экземпляров NSString (или любого подкласса NSObject) - плохая идея.
Пойдите с обычными объектами, пока не достигнете измеримого узкого места производительности. Ive использовал высокоуровневый код даже в жестких игровых циклах без проблем - обмен сообщениями, классы коллекций, пулы автозаполнения, без проблем.
Struct с NSObject экземплярами в них, безусловно, плохая идея. Вам нужно -init и -dealloc правильно обрабатывать счетчик удержания. Запись retain и releases со стороны вызывающего абонента просто безумна. Он никогда не окупится.
Struct с двумя int или четырьмя double являются пограничными случаями. Сама инфраструктура Cocoa реализует NSRect, NSPoint и т.д. Как структуру. Но этот факт смутил много и много новичков. Честно говоря, даже различие между примитивными типами и типами объектов путало их. Это становится даже запутанным для меня, когда у вас есть Struct как свойства объекта: вы не можете делать
object.frame.origin.x=10;
Если вы начинаете создавать свои собственные Struct s, вам нужно помнить, что именно. Это снова хлопот. Я думаю, что причина, по которой они (NSRect и т.д.) Struct, в основном исторические.
Я бы предпочел сделать все объекты. И используйте сборку мусора, если она доступна.
И, не спрашивайте людей, стоит ли что-то оптимизировать или нет. Измерьте его самими инструментами или что-то еще. В зависимости от среды (ppc vs intel, OS X vs iOS, iPad против iPhone) один из способов, который был быстрее в предыдущей системе, может быть медленнее в новой системе.
Объект Objective C имеет почти то же хранилище, что и структура, за исключением того, что он имеет размер 4 байта (8 байт на 64 бит). Это он - всего лишь один указатель на место, где среда выполнения содержит всю информацию о классе.
Если вы настолько плотно работали в памяти, то теряете 4 байта, но обычно это только для большого количества объектов: 50 000 Nsobjects vs structs - всего 200 кб - вы получаете много материала для этого 200k. Для миллиона объектов стоимость будет складываться на iPhone.
Если вы хотите сказать, что переносить элементы в openGL или нужен массив c для других целей, то другой вариант - сделать ONE NSObject с указателем malloc'ed для всех 50 000 целых чисел. Тогда накладные расходы на объектив c составляют ~ 0, и вы можете инкапсулировать все неприятные файлы malloc и free() во внутренности одного файла .m.
Я вообще не вижу проблемы с использованием структур для хранения небольших количеств примитивных (т.е. не-объектов) типов, где не требуется никакого поведения. Уже есть несколько примеров этого в рамках Cocoa (CGRect, CGSize, CGPoint, NSRange).
Не используйте structs для хранения объектов Objective-C. Это усложняет управление памятью в среде с подсчетом ссылок и может полностью ее повредить в среде GC.
Для меня я бы предпочел использовать обычные объекты, потому что вы можете легко выполнять задачу Object с ним, как сохранение, выпуск, автозапуск. Я вижу только несколько структур в Cocoa Framework, таких как CGSize, CGRect и CGPoint. Я думаю, причина в том, что они много используются
Я считаю, что неплохо использовать структуры специально, если вы имеете дело с основами на основе C, позволяет использовать OpenGL, CoreGraphics, CoreText специально для тех, которые потребуют пары/тройки ints, double, chars и т.д. (If они уже не реализованы в некоторых Apple Framework: CGRect, CGPoint, CTRect, NSRange и т.д.). C играет и выглядит лучше с другими материалами C.
Я не думаю, что напишу подкласс NSObject, содержащий пару ints. Это почти смешно. лол.