- 1
- 2
https://habr.com/ru/post/449368/
Ко-ко-ко-ко-ко-кой багор )))
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
0
https://habr.com/ru/post/449368/
Ко-ко-ко-ко-ко-кой багор )))
>Он будет как С++ только очень хуевый
Я ещё джва года назад это ванговал.
- А я и нProgram halted due to out of memory exception
Чем бы дитя не тешилось, лишь бы графы зависимостей не зацикливало. А с лисами и счётчик ссылок вполне справится.
Да и хуй с ней, если честно. По крайней мере копирование предсказуемо - если я выбираю из гигабайтной строки стометровые куски, я ожидаю что это будет жрать дохуя памяти.
Мне больше нравится схема с явными string (новая строка) и string_ref (ссылка на кусок существующей строки). И лишних копирований нету и бесполезное говно в памяти не копится.
А ref версию всегда можно навернуть поверх обычной. Для тех, кому это реально надо.
Так все в яве и наслаждались O(1), а при необходимости явно писали new String (новая строка).
Пока светлые умы не решили починить обезьянам «утечки».
Это ещё в 7й или 8й версии "починили". Теперь trim работает не за няшные O(1), а за O(N).
А что делать?
В случае 100-мегабайтных строк несложно написать свою реализацию CharSequence c ожидаемым поведением.
>а в стате много воды и петросянства ненужново совершенно
habr.com — дальше не читал.
Вот, те же проблемы в языках с прямым управлением памятью:
http://govnokod.ru/14458#comment214519
Потому кстати у крестухов аллергия от одного слова КУЧА.
На стеке, всё на стеке, лишь бы malloc не тупил и не отдавал null.
Ошибка уже здесь.
Строки из-за своего внутреннего устройства чисто алгоритмически не годятся для мутации гигантских объёмов данных. Там же везде O(N) и копирование вылазит. Например та же конкатенация.
В конечном итоге мы придём к старым-добрым лоу-левел технологиям постраничной адресации в 4k/2Mb. И обёртке в виде CharSequence & Appendable.
Выделяем память chunkами размером в страницу и наслаждаемся O(1) substring, append и малой перепитушнёй размером не больше двух страниц.
Ведь сперва нужно выделить под массив цельный кусок памяти в гигабайт.
А это не так просто как кажется.
Например, у меня на машине свободно 5-6Gb, а свободного нефрагментированого гигабайта нет.
Потому сишкобляди/крестушки и используют всякие кастомные аллокаторы вроде jemalloc. Не от хорошей жизни это.
>значит тебя ждет свап
Не совсем. jvm всё-таки держит свободоное место дефрагментированным.
А фрагментированные объекты, пережившие сборку, копирует в другое место, уже без фрагментации.
*В новых сборщиках оно устроено несколько иначе. Но эти сборщики заточены под 10/100 гигабайтные кучи
Да все знали про это.
Ещё помню очень давно на ГК был пост в стиле
На что было указано, что не факт что это говно. Если s=bigString.substring(...)
Т.к. он выполняет копирование, выделяя новую память.
Когда люди делали такой конструктор, они ведь что-то соображали.
А они там не пробовали сделать просто new String(pituh)?
Почтовая рассылка есть?
Пошлите гонца.
Нужно откровение от самого Бога.
Там было что-то короткое new String(str)
Типа такого: http://govnokod.ru/17878#comment269223