На 19:50 начинается странная дичь. Я, конечно, со второго раза таки понял, что Алексей говорит о потере производительности при пересчёте хэшкода, если он как раз попадает на нуль, но при проверке у себя я такой аномалии не обнаружил. При первом расчёте хэшкода есть аномалия по времени его вычисления, но повторные расчёты хэшкода выполняются очень схоже. Вот данные: строка - хэшкод - время расчёта хэшкода, нс сверхинструментом пренебрегшая: 0, 56909 сверхинструментом пренебрегшая: 0, 928 пренебрегшая сверхинструментом: 462434972, 619
Потеря производительности когда хеш случайно стал 0 заключается в том, что хеш будет вычисляться каждый раз когда вызывается hashCode() и не будет закеширован. У первой строки хеш-код 0. И будет каждый раз вычисляться. У второй строки хеш-код не равен 0 и будет закеширован. И получить его значение можно из кеша внутри строки.
20:31 Я так и не понял ответа, почему время получения кеша двух одинаковых по длине строк на порядок отличается? Может кто-нибудь пояснить, плз? Алексей сразу прыгнул на другую тему с аномалией кеша хешкода равному нулю.
Ааааа... т.е., видимо, у первой строки анамальный хешкод и из-за этого тест очень длинный (т.к. много итераций прогоняется и каждый раз хешкод считался снова и снова), а у второй - обычный и поэтому хешкод один раз рассчитался, а потом просто возвращался - в среднем на много итераций время получилось очень малым. Верно? Спасибо.
Кешировать хешкод в строке вообще сомнительная затея как по мне. Из-за этого объект строки распух на 8 байт - 4 байта int хешкода и 4 байта на выравнивание (т.е. вообще неиспользуемое место). В результате 24 байта, а если убрать хешкод то строка будет занимать 16 байт. Это может показатся экономией на спичках, но нужно не забывать что кешлайн процессора всего 64 байта Всё таки большинство строк не участвуют как ключи для хешмапов. А даже если участвуют то это лучше заоптимизировать компилятором там.
Шипилёв: в String нет места для дополнительного флажка, распухнет на 8 байт Также Шипилёв, парой лет позже: а давайте кодер в String сохраним, вроде и место для него на всех мэйнстримных платформах есть!
На самом деле не бред. В частности про методы работы с памятью. Хотя да 40% размышлений и методологим было изложено ещё в доке по jdk 1.1 - например рекомендации по быстрому конкату строчек.
Смотришь Шипилева и настроение улучшается.
Шикарный доклад! Много нового узнал.
Хороший доклад. Правильно говорит, что нельзя опираться на советы, нужно самим проводить проверки и на своих задачах.
а что его спросили на 46:20?
:)
Очень!
отличный доклад.
хорошо рассказывает, не устаешь слушать как от некоторых
Шикарный доклад !
Гений!
На 36 слайде минуса не хватает или a(n-1) и b(n-1) местами поменять надо.
На 19:50 начинается странная дичь. Я, конечно, со второго раза таки понял, что Алексей говорит о потере производительности при пересчёте хэшкода, если он как раз попадает на нуль, но при проверке у себя я такой аномалии не обнаружил. При первом расчёте хэшкода есть аномалия по времени его вычисления, но повторные расчёты хэшкода выполняются очень схоже. Вот данные:
строка - хэшкод - время расчёта хэшкода, нс
сверхинструментом пренебрегшая: 0, 56909
сверхинструментом пренебрегшая: 0, 928
пренебрегшая сверхинструментом: 462434972, 619
Потеря производительности когда хеш случайно стал 0 заключается в том, что хеш будет вычисляться каждый раз когда вызывается hashCode() и не будет закеширован.
У первой строки хеш-код 0. И будет каждый раз вычисляться.
У второй строки хеш-код не равен 0 и будет закеширован. И получить его значение можно из кеша внутри строки.
Ну булеан таки сделали да? :)
20:31 Я так и не понял ответа, почему время получения кеша двух одинаковых по длине строк на порядок отличается? Может кто-нибудь пояснить, плз? Алексей сразу прыгнул на другую тему с аномалией кеша хешкода равному нулю.
Так это не другая тема - у одной из этих строк hashCode() == 0, из-за этого и случается аномалия
Ааааа... т.е., видимо, у первой строки анамальный хешкод и из-за этого тест очень длинный (т.к. много итераций прогоняется и каждый раз хешкод считался снова и снова), а у второй - обычный и поэтому хешкод один раз рассчитался, а потом просто возвращался - в среднем на много итераций время получилось очень малым. Верно? Спасибо.
Не понимаю. Если intern такой перегруженный, то почему в него кладутся ВСЕ литералы ???
Кешировать хешкод в строке вообще сомнительная затея как по мне. Из-за этого объект строки распух на 8 байт - 4 байта int хешкода и 4 байта на выравнивание (т.е. вообще неиспользуемое место). В результате 24 байта, а если убрать хешкод то строка будет занимать 16 байт. Это может показатся экономией на спичках, но нужно не забывать что кешлайн процессора всего 64 байта
Всё таки большинство строк не участвуют как ключи для хешмапов. А даже если участвуют то это лучше заоптимизировать компилятором там.
Почему так похоже на пересказ главы про String’и в Эккеле?)
Шипилёв: в String нет места для дополнительного флажка, распухнет на 8 байт
Также Шипилёв, парой лет позже: а давайте кодер в String сохраним, вроде и место для него на всех мэйнстримных платформах есть!
Да, тоже заметил. Но там вроде только в 64 битных VM место есть, если я правильно понял.
Так кодер и нужен для экономии памяти на самих символах, тут выигрыш гораздо больший чем размер одного кодера
Я не понял, почему нельзя хешкод вычислить сразу при создании строки и брать его всегда готовым. Без этой свистопляски с кешированием.
вычислять хэш дороговато, нужно пробежаться по всем символам строки. поэтому хэш вычисляется только если нужно сравнить эту строку с чем-то.
@@НайманКопеев зато при каждом последующем сравнении быстрее работать будет, это важнее.
Он и берётся всегда готовым, т.е. кешируется. Просто рассчитывается не сразу, а только при первом обращении.
Не всегда хеш нужен.
А где слайды можно скачать?
раздвоение личности? )))
Нет, просто решил себя не утруждать поиском, но потом устал ждать ответа и решил взять инициативу в свои руки ;)
Глупец какой-та.
школота, ты каналом ошиблась )))
Целый час бред про стринг. Надо быть упоротым ,чтобы такое количество времени убить на это.
На самом деле не бред. В частности про методы работы с памятью. Хотя да 40% размышлений и методологим было изложено ещё в доке по jdk 1.1 - например рекомендации по быстрому конкату строчек.