Объект кругового буфера Obj-C, реализующий один?

Question

Я разрабатывал для iPhone довольно долгое время, и мне было интересно, есть ли какой-нибудь объект массива, который использует циклический буфер в Obj-C? Как в стеке Java, списке или очереди. Я возился с NSMutableArray, тестировал его ограничения ... и кажется, что после 50 тыс. Простых объектов внутри массива - приложение значительно замедляется.

Итак, есть ли лучшее решение, кроме NSMutableArray (которое становится очень медленным с огромными объемами данных). Если нет, то может ли кто-нибудь рассказать мне о способе создания такого объекта (будет ли это связано с использованием объектов цепочки (узла) ??).

Итог: заполнение UITableView из базы данных SQLite было бы разумным? Поскольку это не потребует памяти от массива или чего-либо, но только запросов. И SQLite работает быстро и не перемалывает память.

Большое спасибо за ваше время и внимание, ~ Натанавра.

---

Из того, что я думал, кажется, что посещение класса Куинн - лучший вариант, возможно. У меня есть другой вопрос - будет ли быстрее или умнее загружать все прямо из БД SQLite, а не создавать объект и помещать его в массив?

Спасибо заранее, ~ Натанавра.

Answer 1

Извиняюсь за то, что у меня есть собственный рог, но я реализовал кольцевой буфер на основе C в CHDataStructures . (В частности, проверьте CHCircularBufferQueue и CHCircularBufferStack.) Проект с открытым исходным кодом и имеет тесты, которые демонстрируют, что настоящий круговой буфер довольно быстрый по сравнению с NSMutableArray в общем случае, но результаты будут зависеть от ваших данных и использования , а также тот факт, что вы работаете на устройстве с ограниченным объемом памяти (например, iPhone). Надеюсь, это поможет!

Answer 2

Если вы видите проблемы с производительностью, измерьте, где ваше приложение тратит свое время, а не просто догадывайтесь Apple предоставляет отличный набор инструментов для измерения производительности.

Answer 3

Тривиально, что массив NSMutable действует как стек, список, очередь и т. Д., Используя различные методы insertObject:atIndex: и removeObjectAtIndex:. Вы можете написать свои собственные подклассы, если хотите жестко связать поведение.

Я сомневаюсь, что проблемы с производительностью, которые вы видите, вызваны NSMutableArray, особенно если ваша точка отсчета гораздо, гораздо медленнее Java. Проблема скорее всего в самом iPhone. Как отмечалось ранее, 50000 объектов target-c - это не тривиальный объем данных в этом контексте, и аппаратное обеспечение iPhone может с трудом управлять таким количеством данных.

Если вам нужен какой-то высокопроизводительный массив для байтов, вы можете использовать один из базовых базовых массивов или свернуть свой собственный в простой C, а затем обернуть их в пользовательский класс.

Мне кажется, что вам нужно переключиться на основные данные, чтобы вам не приходилось хранить все это в памяти. Основные данные будут эффективно извлекать то, что вы хотите, только тогда, когда вам это нужно.

Answer 4

Вы можете использовать классы STL в "Objective-C ++" - это причудливое имя для Objective-C, использующего классы C ++. Просто назовите те исходные файлы, которые используют код C ++ с расширением ".mm", и вы получите смешанную среду выполнения.

Answer 5

Объекты Objective-C на самом деле не "простые", поэтому 50 000 из них будут довольно требовательными. Напишите свое собственное на простом C или C ++, если вы хотите избежать узких мест и потребностей в ресурсах среды выполнения Objective-C.

Довольно длительное и не теоретическое обсуждение накладных расходов, связанных с удобством:

http://www.cocoabuilder.com/archive/cocoa/35145-nsarray-overhead-question.html#35128

И простая математика для простых людей:

Все, что требуется для создания объекта в отличие от структуры, - это один указатель в начале.

Допустим, это правда, и предположим, что мы работаем в 32-битной системе с 4-байтовыми указателями.

4 байта x 50000 объектов = 200000 байтов

Это почти 200 МБ дополнительной памяти, которая нужна вашим данным внезапно только потому, что вы использовали Objective-C. Теперь соедините это с тем фактом, что независимо от того, какой NSArray вы добавляете, эти объекты к удваивают это, сохраняя свой собственный набор указателей на эти объекты, и вы просто жуете 400 МБ ОЗУ, чтобы вы могли использовать пара удобных оберток.

Обновите мою память здесь ... Файлы подкачки на жестких дисках работают так же быстро, как и ОЗУ? Сколько оперативной памяти есть в iPhone? Сколько вызовов функций и стековых фреймов требуется, чтобы отправить объекту сообщение? Почему IOKit не написан на Objective-C? Сколько из ведущих приложений Apple, которые используют DSP, используют AppKit? У кого-нибудь есть копия otool, с которой они могут проверить? Я вижу ноль здесь.