Алексей Шипилёв - Катехизис java.lang.String
ฝัง
- เผยแพร่เมื่อ 6 ก.ย. 2024
- Ближайшая конференция - Joker 2024, 9 октября (Online), 15-16 октября (Санкт-Петербург + трансляция).
Подробности и билеты: jrg.su/Ypf1HW
- -
. . . . Алексей Шипилёв, Oracle - Катехизис java.lang.String, Java-конференция JPoint 2015; Москва, 20.04.2015
jokerconf.com - Ближайшее выступление Алексея: Joker 2016, 14-15 октября 2016.
В приложениях кровавого энтерпрайза и прочих продуктах, что так или иначе связаны с обработкой текстовых данных, порядочное количество памяти и времени тратится на возню со строками. Оптимизации работы со строками часто дают немедленный выигрыш, а то и уворачивание от OutOfMemoryError.
В этом докладе будут рассмотрены основные пороки работы со строками: чревоугодие конкатенации, блуд подстрок, корыстолюбие интернирования, гордыню дедупликации и прочее. Кроме того, речь пойдет о том, чего стоит излишняя надежда на JDK и JVM.
Смотришь Шипилева и настроение улучшается.
Шикарный доклад! Много нового узнал.
Хороший доклад. Правильно говорит, что нельзя опираться на советы, нужно самим проводить проверки и на своих задачах.
а что его спросили на 46:20?
:)
Очень!
хорошо рассказывает, не устаешь слушать как от некоторых
отличный доклад.
Гений!
Шикарный доклад !
На 36 слайде минуса не хватает или a(n-1) и b(n-1) местами поменять надо.
Не понимаю. Если intern такой перегруженный, то почему в него кладутся ВСЕ литералы ???
Ну булеан таки сделали да? :)
На 19:50 начинается странная дичь. Я, конечно, со второго раза таки понял, что Алексей говорит о потере производительности при пересчёте хэшкода, если он как раз попадает на нуль, но при проверке у себя я такой аномалии не обнаружил. При первом расчёте хэшкода есть аномалия по времени его вычисления, но повторные расчёты хэшкода выполняются очень схоже. Вот данные:
строка - хэшкод - время расчёта хэшкода, нс
сверхинструментом пренебрегшая: 0, 56909
сверхинструментом пренебрегшая: 0, 928
пренебрегшая сверхинструментом: 462434972, 619
Потеря производительности когда хеш случайно стал 0 заключается в том, что хеш будет вычисляться каждый раз когда вызывается hashCode() и не будет закеширован.
У первой строки хеш-код 0. И будет каждый раз вычисляться.
У второй строки хеш-код не равен 0 и будет закеширован. И получить его значение можно из кеша внутри строки.
20:31 Я так и не понял ответа, почему время получения кеша двух одинаковых по длине строк на порядок отличается? Может кто-нибудь пояснить, плз? Алексей сразу прыгнул на другую тему с аномалией кеша хешкода равному нулю.
Так это не другая тема - у одной из этих строк hashCode() == 0, из-за этого и случается аномалия
Ааааа... т.е., видимо, у первой строки анамальный хешкод и из-за этого тест очень длинный (т.к. много итераций прогоняется и каждый раз хешкод считался снова и снова), а у второй - обычный и поэтому хешкод один раз рассчитался, а потом просто возвращался - в среднем на много итераций время получилось очень малым. Верно? Спасибо.
Почему так похоже на пересказ главы про String’и в Эккеле?)
Кешировать хешкод в строке вообще сомнительная затея как по мне. Из-за этого объект строки распух на 8 байт - 4 байта int хешкода и 4 байта на выравнивание (т.е. вообще неиспользуемое место). В результате 24 байта, а если убрать хешкод то строка будет занимать 16 байт. Это может показатся экономией на спичках, но нужно не забывать что кешлайн процессора всего 64 байта
Всё таки большинство строк не участвуют как ключи для хешмапов. А даже если участвуют то это лучше заоптимизировать компилятором там.
Шипилёв: в String нет места для дополнительного флажка, распухнет на 8 байт
Также Шипилёв, парой лет позже: а давайте кодер в String сохраним, вроде и место для него на всех мэйнстримных платформах есть!
Да, тоже заметил. Но там вроде только в 64 битных VM место есть, если я правильно понял.
Так кодер и нужен для экономии памяти на самих символах, тут выигрыш гораздо больший чем размер одного кодера
А где слайды можно скачать?
раздвоение личности? )))
Нет, просто решил себя не утруждать поиском, но потом устал ждать ответа и решил взять инициативу в свои руки ;)
Я не понял, почему нельзя хешкод вычислить сразу при создании строки и брать его всегда готовым. Без этой свистопляски с кешированием.
вычислять хэш дороговато, нужно пробежаться по всем символам строки. поэтому хэш вычисляется только если нужно сравнить эту строку с чем-то.
@@user-qx2fi9sv7v зато при каждом последующем сравнении быстрее работать будет, это важнее.
Он и берётся всегда готовым, т.е. кешируется. Просто рассчитывается не сразу, а только при первом обращении.
Не всегда хеш нужен.
Глупец какой-та.
школота, ты каналом ошиблась )))
Целый час бред про стринг. Надо быть упоротым ,чтобы такое количество времени убить на это.
На самом деле не бред. В частности про методы работы с памятью. Хотя да 40% размышлений и методологим было изложено ещё в доке по jdk 1.1 - например рекомендации по быстрому конкату строчек.