😐

мне хватает

Это уже другой разговор.

все что не хеш

все шифрую

осенссл + аес 256 с солью

а хешей хватает

Дело не в том, сам по себе хеш это не все, речь же о том, чтоб твоя хештаблица перформила годно.

Ща глянул код
Судя по всему - количество бакетов всегда кратно 16
Даже не так, количество бакетов всегда увеличивается в 2 раза от начального значения, по дефолту 16, т.е. 16 32 64 128 и т.д.
Да и равномерного хеширования все равно не бывает
Плюс я пока не понял, когда именно количество бакетов растет (с телефона не оч удобно код читать, когда его много)
И в принципе,сам код ресайза конечно достаточно объемный, но он не выглядит слишком медленным. В общем, как всегда - все зависит от конкретных данных. Но раз решили оптимизировать именно поиск внутри бакета, значит в среднем по больнице основная проблема была там.

Нет, просто оптимизировать ресацзинг нельзя, я поэтому и спросил об этом. А респцзинг происходит обычно по триггеру типа «переполнение». Переполнение конкретного бакета.

Типа, если больше тысячи элементов, то пора ресайзить.

Но гораздо лучше, конечно, заранее попросить у рантайма сразу 64 бакета, а то и 128. И жить счастливо.

Тут уже замер обычно помогает.

По джавадоку не до конца понятно, но вроде как таки не по конкретному бакету, а по общему количеству объектов.

Это тот же принцип, по переполнению, но метрика другая, тут уже дрочит каждый как любит.

Javadoc с тобой в корне не согласен

Thus, it's very important not to set the initial
* capacity too high (or the load factor too low) if iteration performance is
* important.

😃

Ты почитай внимательно.

Что там написано.

Iteration.