Объект кольцевого буфера Obj-C, реализовывая один?
Я разрабатывал для iPhone в течение достаточно долгого времени, и я задавался вопросом, существует ли какой-либо объект массива что кольцевой буфер использования в Obj-C? Как Стопка или Список Java или Очередь. Я переделывал NSMutableArray, тестируя это - пределы..., и кажется, что после 50k простые объекты в массиве - приложение значительно замедлено.
Так, есть ли любое лучшее решение кроме NSMutableArray (который становится очень медленным с огромными объемами данных). В противном случае кто-либо может сказать мне о способе создать такой объект (который включил бы использующую цепочку (узел) объекты??).
Нижняя строка: Заполнение UITableView от DB SQLite непосредственно было бы умно? Поскольку это не потребует памяти от массива или чего-либо, но просто запросов. И SQLite быстр и не шлифование памяти.
Большое спасибо за Вас время и внимание, ~ Natanavra.
Из того, что я думал, что кажется, что движение для класса Quinn является наилучшим вариантом возможно. У меня есть другой вопрос - это было бы быстрее или более умным загрузить все прямо из DB SQLite вместо того, чтобы создать объект и продвинуть его в массив?
Заранее спасибо, ~ Natanavra.
5 ответов
Прошу прощения за то, что я включил свой собственный рожок, но в CHDataStructures я реализовал круговой буфер на С-образной основе. (В частности, обратите внимание на CHCircularBufferQueue и CHCircularBufferStack.). Проект имеет открытый исходный код и тесты, которые показывают, что настоящий круговой буфер достаточно быстр по сравнению с NSMutableArray в общем случае, но результат будет зависеть от ваших данных и использования, а также от того, что вы работаете на устройстве с ограниченной памятью (например, iPhone). Надеюсь, это поможет!
Если вы видите проблемы с производительностью, измеряйте, где ваше приложение проводит свое время, а не просто угадывайте. Apple предоставляет отличный набор инструментов для измерения производительности
.Классы STL можно использовать в "Objective-C++". - что является причудливым названием для Objective-C, использующим классы C++. Просто назовите те исходные файлы, которые используют Си++ код с расширением ".mm" и вы получите смешанное время выполнения.
. Тривиально, когда массив NSMutable действует как стек, список, очередь и т.д., используя различные методы insertObject:atIndex: и removeObjectAtIndex:. Вы можете написать свои собственные подклассы, если захотите усложнить поведение.
Я сомневаюсь, что проблемы с производительностью, которые вы видите, вызваны NSMutableArray, особенно, если ваша точка отсчета - намного, намного медленнее Java. Скорее всего, проблема в самом iPhone. Как уже отмечалось ранее, 50 000 объектов objective-c - это не тривиальный объем данных в этом контексте, и аппаратуре iPhone может быть сложно справиться с таким объемом данных.
Если вам нужен какой-нибудь высокопроизводительный массив для байтов, вы можете использовать один из основных массивов основы или развернуть свой собственный на простом C, а затем обернуть его в пользовательский класс.
Мне кажется, что вам нужно переключиться на данные ядра, чтобы не хранить все это в памяти. Данные ядра будут эффективно получать то, что вам нужно, только тогда, когда вам это нужно.
Объекты "Объект-С" на самом деле не "простые", поэтому 50 000 из них будут довольно требовательными. Напишите свои собственные на прямом C или C++, если хотите избежать узких мест и требований к ресурсам во время выполнения Objective-C.
Довольно длительное и нетеоретическое обсуждение накладных расходов, связанных с удобством:
http://www.cocoabuilder.com/archive/cocoa/35145-nsarray-overhead-question.html#35128
И некоторая простая математика для простых людей:
Все, что нужно, чтобы сделать объект, а не структуру, это один указатель в начале.
Скажем так, мы работаем на 32-битной системе с 4 байтными указателями.
4 байта x 50,000 объектов = 200000 байт
Это почти 200 МБ дополнительной памяти, которая внезапно понадобилась вашим данным только потому, что вы использовали Objective-C. Теперь усугубим это тем, что какой бы NSArray вы не добавили эти объекты к, он удвоит это, сохранив свой собственный набор указателей на эти объекты, и вы только что пережёвывали 400МБ оперативной памяти, чтобы можно было использовать пару удобных оберток.
Освежите мою память... Файлы подкачки на жестких дисках работают так же быстро, как и оперативная память? Сколько оперативной памяти в iPhone? Сколько нужно вызовов функций и кадров стека для отправки объекта сообщения? Почему IOKit не написан в Objective-C? Сколько флагманских приложений Apple, которые делают много DSP, используют AppKit? У кого-нибудь есть копия отула, с которым можно проверить? Я вижу ноль.