Алексей Шипилёв - Катехизис java.lang.String

Ближайшая конференция - 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.

[@atomic.rabbit]

Смотришь Шипилева и настроение улучшается.

[@НикитаСоколов-ъ7н]

Шикарный доклад! Много нового узнал.

[@НайманКопеев]

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

[@ysparrow1]

Очень!

[@travacry]

отличный доклад.

[@MrJavaNinja]

хорошо рассказывает, не устаешь слушать как от некоторых

[@savar33]

а что его спросили на 46:20? :)

[@wunm6249]

Шикарный доклад !

[@9080artur]

Гений!

[@MacIn173]

На 36 слайде минуса не хватает или a(n-1) и b(n-1) местами поменять надо.

[@СергейСамойлов-м5т]

Не понимаю. Если intern такой перегруженный, то почему в него кладутся ВСЕ литералы ???

[@aljesco8338]

На 19:50 начинается странная дичь. Я, конечно, со второго раза таки понял, что Алексей говорит о потере производительности при пересчёте хэшкода, если он как раз попадает на нуль, но при проверке у себя я такой аномалии не обнаружил. При первом расчёте хэшкода есть аномалия по времени его вычисления, но повторные расчёты хэшкода выполняются очень схоже. Вот данные: строка - хэшкод - время расчёта хэшкода, нс сверхинструментом пренебрегшая: 0, 56909 сверхинструментом пренебрегшая: 0, 928 пренебрегшая сверхинструментом: 462434972, 619

[@garncev]

Потеря производительности когда хеш случайно стал 0 заключается в том, что хеш будет вычисляться каждый раз когда вызывается hashCode() и не будет закеширован. У первой строки хеш-код 0. И будет каждый раз вычисляться. У второй строки хеш-код не равен 0 и будет закеширован. И получить его значение можно из кеша внутри строки.

[@LeMenas]

Ну булеан таки сделали да? :)

[@strash1692]

20:31 Я так и не понял ответа, почему время получения кеша двух одинаковых по длине строк на порядок отличается? Может кто-нибудь пояснить, плз? Алексей сразу прыгнул на другую тему с аномалией кеша хешкода равному нулю.

[@АдамСмит-ы7р]

Так это не другая тема - у одной из этих строк hashCode() == 0, из-за этого и случается аномалия

[@strash1692]

Ааааа... т.е., видимо, у первой строки анамальный хешкод и из-за этого тест очень длинный (т.к. много итераций прогоняется и каждый раз хешкод считался снова и снова), а у второй - обычный и поэтому хешкод один раз рассчитался, а потом просто возвращался - в среднем на много итераций время получилось очень малым. Верно? Спасибо.

[@stokitko]

Кешировать хешкод в строке вообще сомнительная затея как по мне. Из-за этого объект строки распух на 8 байт - 4 байта int хешкода и 4 байта на выравнивание (т.е. вообще неиспользуемое место). В результате 24 байта, а если убрать хешкод то строка будет занимать 16 байт. Это может показатся экономией на спичках, но нужно не забывать что кешлайн процессора всего 64 байта Всё таки большинство строк не участвуют как ключи для хешмапов. А даже если участвуют то это лучше заоптимизировать компилятором там.

[@МатвейКоноплёв-б8ю]

Почему так похоже на пересказ главы про String’и в Эккеле?)

[@АдамСмит-ы7р]

Шипилёв: в String нет места для дополнительного флажка, распухнет на 8 байт Также Шипилёв, парой лет позже: а давайте кодер в String сохраним, вроде и место для него на всех мэйнстримных платформах есть!

[@igorm.9845]

Да, тоже заметил. Но там вроде только в 64 битных VM место есть, если я правильно понял.

[@Sulphuris]

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

[@igorm.9845]

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

[@НайманКопеев]

вычислять хэш дороговато, нужно пробежаться по всем символам строки. поэтому хэш вычисляется только если нужно сравнить эту строку с чем-то.

[@igorm.9845]

@@НайманКопеев зато при каждом последующем сравнении быстрее работать будет, это важнее.

[@strash1692]

Он и берётся всегда готовым, т.е. кешируется. Просто рассчитывается не сразу, а только при первом обращении.

[@garncev]

Не всегда хеш нужен.

[@kalinkaou2767]

А где слайды можно скачать?

[@ВасяВ-ь5м]

раздвоение личности? )))

[@kalinkaou2767]

Нет, просто решил себя не утруждать поиском, но потом устал ждать ответа и решил взять инициативу в свои руки ;)

[@russinwrshi9315]

Глупец какой-та.

[@ВасяВ-ь5м]

школота, ты каналом ошиблась )))

[@jameswebb100]

Целый час бред про стринг. Надо быть упоротым ,чтобы такое количество времени убить на это.

[@iazarov]

На самом деле не бред. В частности про методы работы с памятью. Хотя да 40% размышлений и методологим было изложено ещё в доке по jdk 1.1 - например рекомендации по быстрому конкату строчек.