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