Самое интересное, какое это все значение имеет на практике в

99% реальных практических юзкейсов?

высокое

ноль, просто об этом всегда любят спрашивать на собесах, причём те кто спрашивает часто тоже не понимает устройства мап :)

шо? откуда 0?

Ну я на каждом собесе такие вопросы получаю

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

это правда. но - общую эрудицию проверяет отлично.

Лезть в internals какой то штуки просто так по определению несусветная глупость. Потому что эти internals на то и internals что со временем могут меняться. Причем без предупреждения всех клиентов которые используют фичу извне.

не очень понял. правда что вероятность равна нулю? иметь О(1) в 99% реальных кейсах

коллега! хеш-мапе 50 лет, она не менялась с момента создания. почему вам так дорого ваше невежество?

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

Языку Go нет 50 лет. И я не про устройство Хеш мапы в прицнипе а про упоротость на internals технологии X (в данном случае языка Go)

нулю равна полезность в 99% практических кейсов.

так вопрос же был про вероятность иметь О(1+загрузка) в 99% реальных кейсах, разве нет? и она точно не равна нулю

Вооот, а я о чем, а меня еще невежей всякие обзывают

поиск бакета - O(1), они в массиве лежат поиск значения в бакете - O(1), потому, что бакет ограниченного размера если какой-то бакет разрастается - мапа перестраивается поэтому, в принципе, время поиска зависит от текущих обстоятельств, но на практике этим можно пренебречь

а как же зависимость от качества хеш-кода? в java у объекта есть метод hashCode(), который напрямую влияет на качество и скорость работы Hashmap, так как влияет на количество коллизий. в Го не так?

помоему в java ересь какая-то)

Бакеты лежат в массиве? Если так, то за счет чего там O(1), поиск по массиву же медленнее?

не очень понял. сама Java ересь или реализация HashMap в java - Ересь?

да неужели?!

применительно к мапе качество хеш-функции, в общем, не важно.

а в java Ой как важно

с чего бы?

реализация HashMap с тюнингом алгоритма - вздор

влияет на колличество коллизий. ведь hashCode() можно переопределить

на колличество коллизий влияет размер бакета

правильно. а коллизии при вычислении хешкода влияют на то в какой бакет попадет значение

так перестраивается же мапа, если бакет разрастается

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

нет, не оба. из хеша вычисляется бакет. это O(1) по-любому

здесь говорят что влияет SUHA на производительность https://www.scielo.br/j/pope/a/BvJ9B7mscxZbXW56fpNQwny/?lang=en Поиск в тексте: The actual complexities of searches, insertions and deletions depend on

я нашел логическое объяснение почему HashCode влияет на производительность: Если функция hashCode() "плохая", то бакет будет расти очень быстро и hashMap будет вынужден перестраивать мапу очень часто - а это точно будет влиять на производительность самой мапы

да, так будет