Как стать автором
Обновить

Комментарии 19

Расскажите пожалуйста про реальное применение этого метода. (Не верится что вы затеяли все ради 2Мб.)
Тут действует принцип «а пять старушек уже пять рублей». Биологических видов много, и версий Ensembl'а тоже много :-)
Не автор, но в одном из приложений, над которым я работаю, множество данных хранится в пользовательской сессии. Если не применять никаких ухищрений (не таких жестких, но в принципе похожих на описанный в статье), то размер сессии будет порядка 20 мегабайт. Пользователей на сервере может быть несколько тысяч, вот и приходится оптимизировать.
Архитектуру такого приложения оставим за кадром, это отдельный разговор :)
В игре которую мы делали с другом был использован более простой метод. Для хранения списков различных текстур и объектов сначала всё грузилось в лист а потом, по завершению загрузки, вызывался метод toArray, сохранялся сам массив а лист разрушался.
Arrays.asList(genes.toArray(new String[genes.size()])); примерно это и делает.
А длина строк случайно не фиксированная? Может массив отступов не нужен, в крайнем случае можно попробовать выровнять по максимальной длине строки.
А еще вместо char[] можно использовать byte[] — нам же не нужен весь диапазон utf.
НЛО прилетело и опубликовало эту надпись здесь
Однако в Java 7 эта опция была выброшена. Давая выигрыш в памяти, она всё-таки требовала больших затрат по времени.
Ага, это одна из причин, по которой я не стал проводить замеры с этой опцией. Слишком уж экспериментальная она.
А если даже отвлечься от UseCompressedStrings, то извлечение строк будет копировать буфер (то же касается автоматического формирования строк, как в комментарии от TheShade): каждый get() будет создавать не только объект String, но и ещё новый char[].
НЛО прилетело и опубликовало эту надпись здесь
Это верно, только хотелось на частном примере показать универсальное решение (это же касается комментария с фиксированной длиной строк). Изложенные идеи не закладываются на содержимое строк.
4мб не так много чтобы сильно заморачиваться, если бы речь шла о 4гб, тогда бы другой вопрос, стоит ли все данные хранить в памяти
4Мб лишь пример. Если же речь о 4Гб то, конечно, стоит загружать данные по частям, но разве вам не будет приятно узнать, что вы можете загрузить существенно больше данных одновременно, снижая частоту подгрузок? :-)
Слишком мудрёный способ для обрезания ArrayList. Для этого есть метод trimToSize().
Интересно, не знал про такой метод. Видимо, потому что никогда не создаю переменных типа ArrayList, пользуясь только теми методами, что объявлены в интерфейсе List. Ну да, trimToSize будет эффективнее, если случится так, что текущий размер списка совпадает с числом элементов. Если нет, то разница минимальна, но мой способ подойдёт для любой реализации списка :-)
Я тут пришел к очевидному выводу что на строках впринципе можно сделать достаточно много оптимизаций как по памяти так и по процессорному времени, завязываясь на то, как они используются в конкретном приложении (например тот же String ropes). Например у нас есть десятки тысяч строк которые являются полным путем по дереву до его листа («root/node1/.../nodeN/leaf), которые тоже используются только на чтение — ну чем не простор для творчества…
Соотвественно следущий этап — генеразация более-менее общих кейсов если очень критична производительность: подментять\дополнять в JVM релизацию строк или операций над ними на тот способ, который в данном случае даст наибольший выхлоп. В кластерах где можно выделить группы — есть машины где строки zip-ются или сжимаются образом, как описано в статье, в другой группе используются RopeStrings и т.д. Насколько это вообще может быть полезно и как бы теоретически оценить пользу от такого подхода?
Ну вот пытались это реализовать в пресловутых UseCompressedStrings, вышло только хуже. Всё же само приложение должно подсказывать, как лучше сделать.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории