Re:A new fast hash table in response to Google’s new fast ha...
by utopcell on Tuesday May 29, 2018 @09:28AM
(#17178934)
To be more accurate, binary trees are constructed only after a bucket ends up containing a small number of elements, which should only happen rarely unless a bad hash function is chosen.
Re:A new fast hash table in response to Google’s new fast ha...
by dbaupp on Tuesday May 29, 2018 @12:33PM
(#17180680)
That's defending against hash collisions which isn't what the grandparent is noticing (the slowing down of memory accesses due to not fitting into cache).
Re:A new fast hash table in response to Google’s new fast ha...
by josefx on Tuesday May 29, 2018 @02:01PM
(#17181515)
I think they implemented that change to deal with a denial of service attack in http servers. A malicious client could send a large list of parameters with an identical String::hashCode() value, resulting in a single large bucket. Other workarounds included a size limit on the parameter list or a hash function with some parameters randomized at program start.
Re:A new fast hash table in response to Google’s new fast ha...
by 2FC00C733A55 on Tuesday May 29, 2018 @04:53PM
(#17182836)
FYI this only happens if the objects implement comparable; if you do not, they will not make binary trees.
https://stackoverflow.com/questions/24673567/change-to-hashm...