Я понимаю, что LinkedHashMap на то и хэш, чтобы обращаться к элементам по ключам, но у меня есть дополнительная задача, когда важно как можно быстрее присвоить пару ключ-значение, например на место второй пары записать другую пару ключ-значение. 
Мой грубый подоход базируется на полном поэлементном копировании всего хэша, и вставке пары в нудный момент. Понятное дело это медленный подход, а как или чем взамен LinkedHashMap вы бы могли мне посоветовать пользоваться, главное - это гарантировать, что последовательность элементов в хэше сохраняется ровно такой же какой она сформировалась вначале, когда элементы туда добавлялись.
 

Royan, постановку задачи не понял. тебе нужно максимально быстро заменить уже существующий в Маp объект? ну т.е. ключ тот же но новое значение? или тебе нужно максимально быстро добавлять новый элемент? 

Максимально быстро менять пару (и ключ и значение), по заданному индексу. 

Мне кажется, тогда тебе вообще не Map надо. свою пару ключ-значение опиши каким-нить объектом, и храни такие обекты в LinkedList. 

Стоит ли для хранения пар делать обертку? 
Насколько критичен доступ по ключу?
В случае с предложенным способом, так как доступ к парам нужен прямой

то использовать надо ArrayList а не LinkedList (последователльный доступ)
 Использовать можно только хэш? 

Это сообщение отредактировал(а) ShamanTrirukiy - 25.4.2006, 17:55

А как ты в ArrayList замениш один объект на другой с сохранением индекса? метод ArrayList.set(int index, Object element) познакомит тебя с  UnsupportedOperationException  а вот в LinkedList он реализован, понятное дело  

консоль:
[1, 2, 3]
[4, 2, 3]

Никакого 

Или я что-то не так делаю? 

Хотя, по поводу недопустимости LinkedList-а  я загнался. Сори 

Это сообщение отредактировал(а) ShamanTrirukiy - 25.4.2006, 18:53

Ха люботный случай.  Не был метод set реализован в ArrayList даже в 1.4.2, а в 1.5 - уже реализовали. Я этого не знал.
Но в любом случае именно эта операция в LinkedList должна работать быстрее.
 

Стоп-стоп-стоп. С каких это пор доступ по индексу в связном списке (в котором доступ по определению ПОСЛЕДОВАТЕЛЬНЫЙ) работает быстрее, чем он же, но в списке с ПРЯМЫМ доступом?? 

Подумал на досуге - если пары представлены разными объектами, то действительно стоит, а если одинаковыми - можно попробовать обойтись и массивом.


Таки не загнался! ALKS, на больших объемах данных LinkedList убъёт приложение, а вот ArrayList даст ту самую возможность 

Посмотри исходники, и ты увидишь, что set(int index, Object element) в ArrayList сводится к замене элемента в массиве по заданному индексу

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

ArrayList изначально писался для обеспечения прямого доступа(по индексу), в то время как LinkedList заточен под последовательный доступ, и доступ к элементам в нем упирается в поэлементный обход коллекции.  

Это сообщение отредактировал(а) ShamanTrirukiy - 26.4.2006, 10:38

Внимательно перечетал доку. да LinkedList гомно... я-то наивно полагал что там нечто большее чем тупой сканиннг. могли бы B-дерево организовать что-ли... 

А вообще, если нужна действительно скорость - простые массивы. 

Это сообщение отредактировал(а) ALKS - 26.4.2006, 11:20

Это и есть ArrayList 

вот тут ты ошибаешся и сильно. как раз недавно читал статью. мужик пишет математические алгоритмы. двух и трехмерная упаковка объектов (есть такая область раскрой и упаковка). объектов сотни-тысяч/милионы так вот скорость работы с простыми масивами разительно выше, да и памяти жрет меньше 

у меня в практике был случай - фуззи-поиск по ~300000 коротких строк. коллекции пошли лесом почти сразу и чуть позже пошел лесом String 

вывод такой. если можете изначаьно оченить размер массива и если предполагаете что размр будет большой - ну скажем десятки тысяч элементов и выше - простые массивы.  

ALKS, не могу не согласиться.

На статью линки нет?
  

Это сообщение отредактировал(а) ShamanTrirukiy - 26.4.2006, 12:17

зря ты так на него... Он хорош, когда с массивом чато производятся операции вставки/удаления