C-Struct vs Object

Question

В настоящее время я работаю над симулятором Game of Life от Conway для iPhone, и у меня было несколько вопросов об управлении памятью. Обратите внимание, что я использую ARC.
Для моего приложения мне понадобится большое количество C-стиля structs или объектов Objective-C для представления ячеек. Там может быть несколько тысяч из них, поэтому очевидно, что управление памятью пришло в голову.
Structs Мой аргумент для структур заключается в том, что ячейки не нуждаются в типичных свойствах OO. Единственное, что они будут удерживать, это два значения BOOL, поэтому не будет огромного количества памяти, разжеванной этими ячейками. Кроме того, мне нужно использовать двумерный массив. С structs я могу использовать 2-мерные массивы C-style. Насколько я знаю, в Objective-C нет замены для этого. Я чувствую, что слишком сложно создать объект только для двух булевых значений.
Объекты Objective-C Моим аргументом (и большинством других людей) является то, что управление памятью вокруг объектов Objective-C очень просто и эффективно с ARC. Кроме того, я видел аргументы, что struct не является таким большим уменьшением памяти для объекта.

Итак, мой вопрос. Должен ли я пойти со старой школой, постным и совместимым с двумерным массивом structs? Или я должен придерживаться типичных объектов Objective-C и рисковать дополнительной памятью.

Последующие мысли: если вы рекомендуете объекты Objective-C, предоставьте альтернативный метод хранения, который представляет собой двумерный массив. Это очень важно и является одним из самых больших недостатков в работе с объектами Objective-C.
Thankyou.

Answer 1

«Преждевременная оптимизация - это корень всех злых» ... Если вы пытаетесь построить сервер Game of Life с 100 000 пользователей, играющих одновременно, объем памяти может иметь значение. Для реализации одного человека на любом современном устройстве, даже мобильном, размер памяти довольно академичен. Таким образом, сделайте все, что бы ни играло быстрее и быстрее (лучше) делает код наиболее читаемым и поддерживаемым. Человеческие циклы стоят дороже компьютерных циклов.Предположим, вам понадобилось третье булевое значение для каждой ячейки игры ... не мог бы объект, который вы могли бы продлить, сохранял бы тонну времени, а не индексы жестко заданных массивов? (По этой причине структура намного лучше, чем массив примитивов ...) Я, конечно, использовал более плотные представления данных, но накладные расходы на время программиста должны стоить того. Просто мои $ .02 ...

Answer 2

Если это всего лишь 2 значения BOOL, которые вы собираетесь хранить для каждой ячейки, вы можете просто использовать массив целых чисел для выполнения задания. Например:

Предположим, что два значения BOOL являются boolX и boolY, мы могли бы объединить их в междунар как:

int combinedBool = boolY + (10*boolX); 

Таким образом, вы можете получить два значения BOOL, как:

BOOL boolX, boolY; 
boolX = combinedBool/10; 
boolY = combinedBool%10; 

И тогда вы можете хранить всю доску в виде массива с одним размером целых чисел с индексом каждой ячейки, представленной ((yIndex*width)+xIndex), где width - количество ячеек слева направо на вашей доске и, xIndex и yIndex представляют координаты X и Y ячейки на вашей плате.

Надеюсь, это поможет в управлении памятью и организации ячеек.

Answer 3

Вы можете построить один и проверить его размер с помощью malloc_size(myObject). Тысячи пар болтов будут достаточно маленькими. Фактически, вы сможете сделать объекты более крупными и пользоваться преимуществами дизайна OO. Например, что, если ячейки также содержали указатели на соседние ячейки. Ячейки могли вычислять собственное состояние t + 1 с кэшированным доступом к своим соседям.