Строковые коллекции только для чтения: экономим на спичках

[leventov]

Расскажите пожалуйста про реальное применение этого метода. (Не верится что вы затеяли все ради 2Мб.)

[tagir_valeev]

Тут действует принцип «а пять старушек уже пять рублей». Биологических видов много, и версий Ensembl'а тоже много :-)

[r0zh0k]

Не автор, но в одном из приложений, над которым я работаю, множество данных хранится в пользовательской сессии. Если не применять никаких ухищрений (не таких жестких, но в принципе похожих на описанный в статье), то размер сессии будет порядка 20 мегабайт. Пользователей на сервере может быть несколько тысяч, вот и приходится оптимизировать.
Архитектуру такого приложения оставим за кадром, это отдельный разговор :)

[BlackSwan]

В игре которую мы делали с другом был использован более простой метод. Для хранения списков различных текстур и объектов сначала всё грузилось в лист а потом, по завершению загрузки, вызывался метод toArray, сохранялся сам массив а лист разрушался.

[tagir_valeev]

Arrays.asList(genes.toArray(new String[genes.size()])); примерно это и делает.

[novoselov]

А длина строк случайно не фиксированная? Может массив отступов не нужен, в крайнем случае можно попробовать выровнять по максимальной длине строки.

[ashofthedream]

А еще вместо char[] можно использовать byte[] — нам же не нужен весь диапазон utf.

[Beholder]

Однако в Java 7 эта опция была выброшена. Давая выигрыш в памяти, она всё-таки требовала больших затрат по времени.

[tagir_valeev]

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

[tagir_valeev]

А если даже отвлечься от UseCompressedStrings, то извлечение строк будет копировать буфер (то же касается автоматического формирования строк, как в комментарии от TheShade): каждый get() будет создавать не только объект String, но и ещё новый char[].

[tagir_valeev]

Это верно, только хотелось на частном примере показать универсальное решение (это же касается комментария с фиксированной длиной строк). Изложенные идеи не закладываются на содержимое строк.

[inheaven]

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

[tagir_valeev]

4Мб лишь пример. Если же речь о 4Гб то, конечно, стоит загружать данные по частям, но разве вам не будет приятно узнать, что вы можете загрузить существенно больше данных одновременно, снижая частоту подгрузок? :-)

[Beholder]

Слишком мудрёный способ для обрезания ArrayList. Для этого есть метод trimToSize().

[tagir_valeev]

Интересно, не знал про такой метод. Видимо, потому что никогда не создаю переменных типа ArrayList, пользуясь только теми методами, что объявлены в интерфейсе List. Ну да, trimToSize будет эффективнее, если случится так, что текущий размер списка совпадает с числом элементов. Если нет, то разница минимальна, но мой способ подойдёт для любой реализации списка :-)

[Vanger13]

Я тут пришел к очевидному выводу что на строках впринципе можно сделать достаточно много оптимизаций как по памяти так и по процессорному времени, завязываясь на то, как они используются в конкретном приложении (например тот же String ropes). Например у нас есть десятки тысяч строк которые являются полным путем по дереву до его листа («root/node1/.../nodeN/leaf), которые тоже используются только на чтение — ну чем не простор для творчества…
Соотвественно следущий этап — генеразация более-менее общих кейсов если очень критична производительность: подментять\дополнять в JVM релизацию строк или операций над ними на тот способ, который в данном случае даст наибольший выхлоп. В кластерах где можно выделить группы — есть машины где строки zip-ются или сжимаются образом, как описано в статье, в другой группе используются RopeStrings и т.д. Насколько это вообще может быть полезно и как бы теоретически оценить пользу от такого подхода?

[tagir_valeev]

Ну вот пытались это реализовать в пресловутых UseCompressedStrings, вышло только хуже. Всё же само приложение должно подсказывать, как лучше сделать.