Какая структура данных? LinkedList или любой другой в Java? - PullRequest
3 голосов
/ 28 февраля 2010

У меня есть особые требования к структуре данных, которая будет использоваться в моей программе на Java. Он (структура данных) должен иметь возможность хранить большие объемы данных (не фиксированные), мои основные операции заключаются в добавлении в конце и удалении / чтении с самого начала (списки ссылок выглядят очень хорошо) Но иногда мне нужно удалить и из середины, и именно здесь LinkedLists так болезненны. Может кто-нибудь предложить мне способ обойти это? Или какие-либо оптимизации, с помощью которых я могу сделать удаление менее болезненным в LinkedLists?

Спасибо за помощь!

Ответы [ 5 ]

4 голосов
/ 28 февраля 2010

LinkedHashMap может удовлетворить ваши цели Вы бы использовали итератор, чтобы вытащить вещи с фронта и искать запись по ключу, когда вам нужно было получить доступ к середине списка

3 голосов
/ 28 февраля 2010

LinkedList падает при случайном доступе.Удаление, без поиска произвольного доступа, является постоянным временем и, таким образом, действительно не так уж плохо для длинных списков.

ArrayList, как правило, быстро.Вставки и извлечения из середины выполняются быстрее, чем вы могли ожидать, потому что перемещение блоков памяти на удивление быстро.Удаление и вставка рядом с началом приводят к перемещению всех следующих данных вниз или вверх.

ArrayDeque похоже на ArrayList, только использует кольцевой буфер и имеет странный интерфейс.

Обычный совет: попробуйте.

2 голосов
/ 28 февраля 2010

вы можете попробовать использовать связанный список с указателями после каждого 10000-го элемента, чтобы вы могли сократить время на поиск середины, которую вы хотите удалить. Вот несколько вариантов связанного списка: http://experimentgarden.blogspot.com/2009/08/performance-analysis-of-thirty-eight.html

0 голосов
/ 01 марта 2010

Сначала вам нужно подумать, удалитесь ли вы из центра списка часто по сравнению с длиной списка.Если в вашем списке есть N элементов, но вы удаляете их гораздо реже, чем 1/N, не беспокойтесь об этом.Используйте LinkedList или ArrayDeque по своему усмотрению.(Если ваши списки иногда бывают огромными, а затем уменьшаются, но в основном маленькие, лучше использовать LinkedList, так как легко восстановить память; в противном случае ArrayDeque не нужны дополнительные объекты, поэтому он немного быстрее и компактнее.- за исключением того, что базовый массив никогда не сжимается.)

Если, с другой стороны, вы удаляете немного чаще, чем 1/N, то вам следует рассмотреть LinkedHashSet, который поддерживает очередь связанного списка наначало хеш-набора - но это - это набор, поэтому имейте в виду, что вы не можете хранить дубликаты элементов.Это накладные расходы LinkedList и ArrayDeque, вместе взятые, но если вы часто делаете центральное удаление, это, вероятно, того стоит.

Оптимальная структура, однако - если вам действительно нужнокаждая последняя унция скорости и готовы тратить время на кодирование, чтобы получить его - это будет массив «изменяемого размера» (то есть перераспределяемый, когда он был слишком мал) с круговым буфером, где вы можете убрать элементы из середины, установив ихк нулю.(Вы могли бы также перераспределить буфер, когда слишком много было пусто, если у вас был неправильный вариант использования.) Я не советую кодировать это, если вы действительно не любите кодировать высокопроизводительные структуры данных или не имеете убедительных доказательств того, что это один изключевые узкие места в вашем коде, и поэтому вам это действительно нужно.

0 голосов
/ 28 февраля 2010

LinkedHashMap , вероятно, путь. Отлично подходит для итерации, работы с deque и поиска в середине. Тем не менее, это требует дополнительных затрат памяти, так как вам нужно управлять набором ключей поверх вашей основной коллекции. Кроме того, я думаю, что в удаленных вами пробелах останутся «пробелы», что приведет к непоследовательному набору ключей (хотя и не должно влиять на итерацию).

Редактировать: Ага! Я знаю, что вам нужно: A LinkedMultiSet ! Все преимущества LinkedHashMap, но без набора лишних ключей. Однако использовать его немного сложнее.

...